[Haskell-cafe] Haskell as data manipulation language?

[Dimitry Golubovsky]

Graham & All,

Graham Klyne wrote:

> 
> 1. The lack of variables in Haskell isn't a problem so much as an 
> opportunity to think in new and interesting ways.

What I was trying to say: where in imperative languages there is a 
boundary between in-memory computations and I/O, equivalent semantic 
boundary in functional languages is between stateful and stateless. I. 
e. functional programming is a stateless way to control stateful world 
(remember state-of-the-world-p? :)

> 
> 2. I think that when you talk about "versioning", you come close to a 
> useful way of thinking about mutable data in Haskell.  My understanding 
> is that the "classical" way (i.e. pre-monads) to think of mutable values 
> in functional languages was to model them as a time-sequence of 
> intermediate values, where a function to "update a state" returns the 
> next value in that sequence.  Expressed this way, a practical problem 
> arises that the intermediate values don't (necessarily) go away, 
> creating a potential for exploding storage requirements.  (If, as with 
> document versioning, you want to keep the intermediate values, then you 
> need to figure a way to live with this;  value sharing in pure 
> functional languages is a big help here.)  But often one is only 
> interested in the "latest" or "current" value in the time-sequence.  
> Monads provide a way of capturing this:  the state is implicitly 
> threaded through a sequence of computations (e.g. the expressions in a 
> do-list), with old versions thrown away as new ones are created (unless 
> the state is explicitly saved, which is not always possible).

I was writing about the same, but applied to persistent storage.

I meant that to store a new version, it is sufficient just to store a 
seralized compiled expression which being applied to version N of an 
object evaluates to its version N+1. In other words, store updates 
lazily. If there are too many stored versions (or lazy evaluation takes 
too much time), then at some moment of time the whole expression 
(spanning down to the oldest stored version) may be deserialized, forced 
to evaluate, serialized, and stored. Older versions may be discarded 
after that (unless any other objects refer to them directly).

P.S. A question to those who needs mutable variables: has anybody tried 
Manuel Chakravarty's Haskell Ports Library?

http://www.cse.unsw.edu.au/~chak/haskell/ports/

I spotted it today, but had no time to look at the code and/or try it. 
According to its (rather sketchy) documentation, this library provides 
some mechanisms to simulate varying values as time-sequences (lazy streams?)

Can anyone tell wether it is more/less functional/efficient than IORefs?

Dimitry Golubovsky
Middletown, CT