English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: [Caml-list] Future of labels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-03-30 (10:31)
From: Jacques Garrigue <garrigue@k...>
Subject: RE: [Caml-list] Future of labels
From: David Gurr <gurr@mrs.med.ge.com>

> > On the other hand Manuel expresses an opinion I've heard a few times:
> > moving to label mode might be nice, if the price to pay was not so
> > high.
> That is my feeling.  I appreciate the "new" features in moderation.
> You type checker example is a good one as are the use of objects in
> ocamlop. But I like being able to bootstrap Ocaml from the (caml-light 
> equiv.) core langauge.  So I would like to remove labels from the
> standard library and the bytecode compiler code (I haven't looked
> carefully but I dont remember any there).

Indeed, the bytecode compiler is very conservative (and has to be so).
You will find some decorative labels in asmcomp (not mine).

The reason we allow labels currently in the standard library
(interfaces only) is that they are ignored in classic mode.
If they are no longer ignored by the default mode, they will of course
have to go.

> > So, you are rather a frustrated potential label mode user than a happy
> > classic mode user ?
> Mostly a caml-light mode user but I use the ocaml extensions when they clean
> up otherwise messy code.  I got pretty frustrated when I wanted to
> compile (IMHO perfectly fine) 2.x code together with lablegtk.  If
> there was a 2.x to 3.x translator that added the labels for me, I would have
> been merely anoyed with the added verbage.  Removing labels from
> the standard library doesnt help if someone label-ifies another
> pre-3.00 library that I am using.

Always the same confusion: you don't have to use label mode for
lablgtk. Unison's GUI is rather large, and is completely written in
classic mode.

Concerning 3rd party libraries, this might of course be a problem, but I
would expect a much smaller impact. The authors will take responsible

> Although I'm in agreement with maf, I dont think that I would be
> happiest with option 3.
> I don't like having both label and classical.

Well, getting everybody to agree on a single mode is not going to be
easy... More seriously, I insisted that this nolabel mode would be
demoted, just kept for people with a fundamental allergy to labels
(why not?), or some relabeling magic.
The main problem with having two modes currently is that people
wrongly assume that they have to be in one to do the work, while it
can be done efficiently in both (independently of the libraries!).

> I think that label is best in the long run.
> I think what I want are
> -- label mode only
> -- restrained labels in the standard library
I think none by default is more reasonable.
But it might be nice to keep the labels in otherlibs like Unix.
They would of course stay in LablTk :-)

> -- a 2.x to 3.x translator
Not needed, as long as we remove labels from the standard library.
Really, such a translator is possible, but I don't like very much the
idea of a program fiddling with my code...
Remark that this would not be a 2.x to 3.x translator, but a classic
to label translator.
Anyway the translator only fixes your code, not your habits.
My intimate belief is that changing habits takes longer than changing
code, and by translating by hand you will learn faster :-)
(maybe not currently valid, because of the standard library)

> -- a (partial) 3.x to 2.x translator that complains & gives up when 
> there is not an obvious 2.x translation but good enough to de-label
> the standard library.
Possible again, but much more work: we must type the program, apply
some non-trivial transformations to it, and output it again. An early
version of olabl based on caml-light worked that way, but honestly
this was a pain.
Also, compiling optional arguments that way would produce really
obfuscated code.

> So what about ~f:?  I dont like ~f: and you do.  Suppose I had an
> editor that puts in the ~f: for me AND hides it so I won't see it
> in the cases when it is in the first arguement?  Or even better,
> the editor takes your code with the :) backwards arguement order,
> puts the arguements in the :) proper order and hides the ~f: 
> :) cruft.  Now I even happy with the most excessively label'd
> libraries.  I think.  

Well, this would still mean two modes. I don't think that classic and
label are bad in this meaning: they were design to interact properly.
But people are always going to meddle with each other, and you want to
be able to exchange code snippets by mail for instance.


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