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

[Judicael Courant <Judicael.Courant@lri.fr>]

Jacques Garrigue a écrit :

[...]
> But if we manage well the transition, I believe we can keep most of
> the advantages of classic mode, while getting labels out of the way of
> beginners.
> 

I think beginners are not the problem. Explaining that you have labels
and that arguments may commute seems quite easy to me (of course I will
have to revise my teaching material, but I think that is another point).
At least it is an order of magnitude easier than explaining partial
application and currying (that is, if you do not consider optionnal
arguments).

To address Benjamin Pierce's concerns, I think teaching Java is another
problem as in Java you have no toplevel, so you must use the standard
library for doing I/O from the beginning. When beginning to teach Caml,
you can use the toplevel and therefore ignore the standard library for a
while (although I would not advocate for it, we have a "functionnal
approach" undergraduate course here that completely ignores currying
hence the standard libray for a whole semester!)

Rather, I am concerned with upward compatibility.

[NB: In the following, I often use "should". Please consider there is an
"In my humble opinion" before each of these uses]

You should not sacrifice the Right Way (tm) for compatibility. I mean,
the default way to write a program should be the Right Way (i.e. with
labels): you should encourage people writing a new program/module to use
labels (while allowing people to compile their old code with few
changes).

> First, concerning the standard library, an idea would be to first
> remove all labels from the default versions, but then add labelized
> versions of some specific functions with a different name (adding a
> "'" for instance).
> I mostly think of: Pervasives.output', Pervasives.input',
> Pervasives.really_input', Array.blit', String.blit';
> and maybe also String.sub', String.fill', Buffer.add_substring',
> Hashtbl.add', Map.add'.

So I think this is the Wrong Approach (tm). Instead, you should provide
an CompatLib (or WithoutLabels) compatibility module for old code and a
possibly a flag for compiling code with an implicit "open CompatLib". As
for other libraries, the Right Way is to have the default libraries with
labels also. Then either you suggest them to move to the Right Way, or
you provide them the needed CompatLibs. BTW, I guess writing a tool for
"unlabeling" a library would be quite easy, would not it? (parse the mli
of the labeled library, remove labels for producing the corresponding
unlabeled mli, and generate the wrapper ml file --- the only difficult
part is with concrete types). Such a tool would let you focus only on
the maintenance of one library. Moreover, after some time, you could
decide to remove support for CompatLibs while still let people
explicitly generate their own unlabeled libraries with this tool.

Sincerly yours,

Judicaël.
-- 
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
"Montre moi des morceaux de ton monde, et je te montrerai le mien"
Tim, matricule #929, condamné à mort.
http://rozenn.picard.free.fr/tim.html
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr