> Markus Mottl <mottl@miss.wu-wien.ac.at> writes:
> 
> [...]
> > There is even a much more radical approach concerning OO: Make all
> > basic types classes! This would e.g. allow to put all kinds of
> > values into a list and iterate it with a print function - just one
> > of many other then possible things I miss...
> 
> I'm not sure this is such a good idea for CAML. The non-OO part of
> CAML is quite mature, while the OO part is more like research. Forcing
> everybody to use CAML as an OO language is IMHO not a very nice thing.
> I do not use the OO part of CAML at all right now, and I'm pretty sure
> I'm not the only one. I think we need more experience with the OO part
> of CAML (or, more fundamentally with OO programming in a functional
> language) before choosing to use it for basic types.
> 
> Don't get me wrong, I have nothing against purely-OO languages. I
> *love* Self, Smalltalk, ... I just think that it's not appropriate for
> CAML at this time. Later, when we have more experience, maybe, but not
> now.

I didn't say that one should be forced to use objects (I sometimes prefer
modules - or even have to take them).

But I think it would be possible to let people use all basic types
as if they were classes without breaking code of other people.  Thus,
if someone doesn't like objects - he needs not necessarily use them.

I wonder whether this is a big task for camlp4 - translating every
appearance of a basic type in the source to an appropriate construction
of an object and all standard functions to appropriate method calls.
I am not so experienced in camlp4, but I believe it could work.

So there is no need to change the compiler - especially, since the
OO-system is still under development. Changing just the preprocessor
(the rules) is certainly not so much work.

> [...]
> > As Okasaki shows, most kinds of data structures can be implemented
> > in a very efficient and still purely applicative way. I am not sure
> > whether there are many data structures that deserve their existence
> > in both forms...
> 
> I think that having arrays with in-place modification is almost a
> must, for example. For some applications, having only functional
> arrays is pretty awful.

Although there are more or less efficient implementations of functional
arrays, I would not want to trade them against "real" arrays (not yet).

As I wrote above (probably just a misunderstanding):

  I am not sure whether there are many data structures that deserve
  their existence in *both forms*...

I don't want to have everything functional nor everything imperative
(of course), but I definitely don't want to have both versions if they
otherwise behave exactly the same (time/memory complexity, comparable
performance). I think this would lead to a lot of confusion (which one
to choose now?).

> I agree with you that for some data-structures, having a
> non-functional version when the functional one is efficient is maybe
> not such a good idea.

Exactly my opinion.

Best regards,
Markus

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl