From: Markus Mottl <email@example.com>
Subject: Re: Looking for a nail
To: firstname.lastname@example.org (Michel Schinz)
Date: Thu, 28 Jan 1999 15:13:09 +0100 (MET)
In-Reply-To: <email@example.com> from "Michel Schinz" at Jan 28, 99 10:54:29 am
> Markus Mottl <firstname.lastname@example.org> 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
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.
-- Markus Mottl, email@example.com, http://miss.wu-wien.ac.at/~mottl
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:18 MET