From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA03070; Fri, 14 Feb 2003 18:53:02 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA03066 for ; Fri, 14 Feb 2003 18:53:01 +0100 (MET) Received: from grace.speakeasy.org (grace.speakeasy.org [216.254.0.2]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h1EHr0f01425 for ; Fri, 14 Feb 2003 18:53:00 +0100 (MET) Received: (qmail 27295 invoked by uid 36130); 14 Feb 2003 17:52:58 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Feb 2003 17:52:58 -0000 Date: Fri, 14 Feb 2003 09:52:58 -0800 (PST) From: brogoff@speakeasy.net To: "caml-list@inria.fr" Subject: Re: feature priorities (was Re: [Caml-list] Request: matrix_init function in Array) In-Reply-To: <87of5gp0ia.fsf_-_@uga.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I'm of the opinion that the implementors know best how to set their priorities, so I don't feel compelled to volunteer their time for the projects I find important. It's like that sign around the public swimming pools when I was growing up which said something like "Don't pee in our pool and we won't swim in your toilet." That said, it would be nice if there were some sort of roadmap which mentioned what was being planned for the future, with the understanding that anything could change, that there would be no hard dates for features, and that whiners who kept haranguing the list about their favorite feature would be shot in the stomach, rolled in honey, and staked to a fire-ant mound in the desert sun. My own short-list is very different from Ed's, as I don't care too much about multithreading right now. Also, I try to separate *language* features from implementation/library features. So, while I'd love it if I could call ocamlopt generated native code from bytecode programs, or have a MLton style supre-duper global optimizer, or have unsafe ops in Bigarray, those aren't on my short list. So, at the risk of exposing myself to the punishment I describe above, here it is, in roughly descending priority, with the caveat that I may change my mind at any time (1) Extensional polymorphism, since that brings type safe value IO, overloading, and dynamics to ML. (2) Some way to make type definitions which had a type expression and a functor instantiation in a recursive relationship. I suppose that for all intents and purposes that is the same as recursive modules. (3) More polymorphic records, a la SML#, or something like that. (4) Some way to extend the class of tail recursive functions, as discussed recently in this list. -- Brian PS: If you want to flame about my choices, at least do so in a useful manner. At least it's a more interesting topic to me than the endless license flamewar ;-). On Thu, 13 Feb 2003, Ed L Cashin wrote: > Chris Hecker writes: > > ... > > I can name probably 20 equivalently sized > > tasks that would help way more people who are trying to use caml and > > answer way more future questions, and that only the core team can do. > > As a new ocaml user, the two biggest missing features appear to be > > 1) a.) no multi-threading support where threads would migrate > between processors > b.) ... which has underlying it: no MT-safe (and efficient) > garbage collector > > 2) ocamlopt-generated programs cannot dynamically load > ocamlopt-generated code. > > Please correct me if I'm wrong about these two. I don't know whether > people are already working on this or even if anyone cares about these > features. I gave a presentation on ocaml to a linux user group > recently, and these two are the only shortcomings I could identify. > Everything else was radient praise. > > -- > --Ed L Cashin | PGP public key: > ecashin@uga.edu | http://noserose.net/e/pgp/ > ------------------- > To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr > Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners