Re: feature priorities (was Re: [Caml-list] Request: matrix_init function in Array)

[brogoff@speakeasy.net]

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 <checker@d6.com> 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