caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: gurr@mrs.med.ge.com, caml-list@inria.fr
Subject: RE: [Caml-list] Future of labels
Date: Fri, 30 Mar 2001 19:31:21 +0900	[thread overview]
Message-ID: <20010330193121X.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <200103300810.AAA05312@mrs.mrs.med.ge.com>

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
decisions.

> 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.

Cheers,

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


       reply	other threads:[~2001-03-30 10:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200103300810.AAA05312@mrs.mrs.med.ge.com>
2001-03-30 10:31 ` Jacques Garrigue [this message]
2001-04-11  3:35 G Michael Sawka
  -- strict thread matches above, loose matches on Subject: below --
2001-03-31  3:40 Yaron M. Minsky
2001-03-29 23:47 Arturo Borquez
2001-03-29 19:56 Manuel Fahndrich
2001-03-30  3:01 ` Jacques Garrigue
2001-03-30  8:23   ` Markus Mottl
2001-03-30  9:45   ` kahl
2001-03-30 10:43     ` Jacques Garrigue
2001-03-30 12:32       ` Benjamin C. Pierce
2001-03-30 10:39   ` Judicael Courant
2001-03-30 10:54     ` Jacques Garrigue
2001-03-30 11:22   ` Francois Pottier
2001-03-30 12:41     ` Benjamin C. Pierce
2001-03-30 14:16       ` Jean-Marc Alliot
2001-03-29  0:44 Jacques Garrigue
     [not found] ` <AAEBJHFJOIPMMIILCEPBEEFHCHAA.mattias.waldau@abc.se>
2001-03-29  6:43   ` Jacques Garrigue
2001-03-29 11:44     ` Mattias Waldau
2001-03-29 17:52     ` Mattias Waldau
2001-03-29  8:22 ` Chris Hecker
2001-03-29  9:46 ` Markus Mottl
2001-04-09  1:28   ` John Max Skaller
2001-04-09  8:45     ` Markus Mottl
2001-04-10 18:42       ` John Max Skaller
2001-04-10 22:01         ` Markus Mottl
2001-03-29 12:53 ` Judicael Courant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010330193121X.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=gurr@mrs.med.ge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).