From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA04631 for caml-redistribution; Thu, 28 Jan 1999 20:58:50 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA07911 for ; Thu, 28 Jan 1999 15:13:41 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id PAA12402 for ; Thu, 28 Jan 1999 15:13:39 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id PAA10768; Thu, 28 Jan 1999 15:13:09 +0100 (MET) From: Markus Mottl Message-Id: <199901281413.PAA10768@miss.wu-wien.ac.at> Subject: Re: Looking for a nail To: michel.schinz@csem.ch (Michel Schinz) Date: Thu, 28 Jan 1999 15:13:09 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: from "Michel Schinz" at Jan 28, 99 10:54:29 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis > Markus Mottl 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