Re: [Caml-list] Future of labels, and ideas for library labelling

[Chris Hecker <checker@d6.com>]

>        I've always thought finishing a job was a sensible
>high priority.

Fair enough, especially if there's a spirit of compromise.  I think people (myself included) were simply reacting against the rather extreme suggestions that seemed to be going around from both sides.

Since I've been labeled (!) as a classic mode user in this discussion, I should point out that I am actually a label mode user since all of my ocaml code uses lablgl and labltk, and so I'm forced to use label mode.  I don't mind it, and I've actually written useful functions with optional arguments, commutation, and whatnot.  

My only request is still that if there's no ambiguity, don't require labels even in label mode.  

Of course, I reserve the right to request more features as I write more code.  :)  I've actually written a fair amount of "real" code over the past few weeks, so I'm starting to get more confidence in my knowledge of the language, but I'm still a long way off.

I'm a bit concerned by the currying-with-labels discussion, but I definitely don't understand all the issues there, so I can't weigh in with my [extremely valuable, I'm sure :) ] opinion.  I've run into this before, I think, but I can't remember the circumstances.  As I've been getting more comfortable with functional programming, I've been using currying more and more, and labels should definitely play nice with it.  I guess that means not forcing eta expansions very often just to rename parameters, among other things.  I wonder if that problem would go away if the "don't force labeling when unambiguous" feature was added...

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr