>> You're fascinated by mutable arrays, aren't you? :-)
> 
>   I suppose I just can't get over the mentality that arrays are the
> fastest possible data containers for random access, that random access
> is required for very many algorithms, that many algorithms require
> modifying the data in the array, and that an array is one of the most
> memory-efficient ways of storing data in memory (in certain circumstances
> there are even more space-efficient ways, but those are a bit exceptional
> cases).

All valid points of course. (Indeed, in languages like Pascal, you'd be 
forgiven for thinking that arrays are the *only* container type.)

Oddly enough, I don't often find myself wanting to use arrays. I guess 
this is just an artifact of the kinds of programs I tend to write. If I 
was doing lots of image processing or DSP or something then I'd almost 
certainly want arrays. But many of the programs I write involve parsing 
some text input to generate a small parse tree, processing that tree 
according to some highly complex algorithm, and writing the result back 
out. There isn't much call for an array in there. (Although I commonly 
want dictionaries, which you could conceivably implement as hash tables 
instead of trees.)

>   I'm curious: Were mutable arrays a later addition to the Haskell language?
> Did it start as a pure functional language, but mutable arrays were added
> later because pure functionality is *not* the silver bullet?-)

I wasn't there, but as I understand it, Haskell has had mutable arrays 
for a very long time now. (E.g., they are explicitly mentioned in the 
current language standard document, circa 1998.)

Monadic I/O was definitely a later addition; Haskell used to have a much 
more chunky I/O system based on infinite lazy lists. (A Haskell 
"program" takes an infinite list of I/O responses as input, and returns 
an infinite list of I/O requests as output. If that sounds confusing - 
it is. And it's very easy to get wrong!)

As for pure functional programming... it has many attractive properties. 
It is self-evident that a complete program that is *totally* pure is 
formally equivilent to a null program, so that isn't very useful. 
Different functional languages solve this problem in different ways:

- SQL, while not technically a "functional" language, solves it by being 
a special purpose language who's purpose is to return results to the 
caller who then actually "does" stuff with it. (Oh, and by having DML 
statements.)

- Lisp does it by being impure. (I.e., if you want to mutate something, 
you just mutate it. But you're supposed to "avoid" doing that too much.)

- Clean does it using an interesting concept known as "uniqueness 
typing". (Basically works like Lisp, except the type system enforces 
some constraints.)

- Haskell uses monads instead. (It's a simple way to structure I/O, and 
turns out to be useful for many other things too.)

- I have no idea what Erlang does...

Silver bullet? No. Useful? Well, I think so. But then, I'm biased. ;-)

Post a reply to this message