RE: [Caml-list] Future of labels

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

Nice, it seems that we can have a relaxed discussion this time :-)

OK, I'll first try to  correct some (potential) misunderstandings.

* I'm not sure this is a misunderstanding, but at least it may seem
  that some (Chris, Arturo) are implying that optionals argument do
  not commute in classic mode. They do commute in both classic and
  label mode, and there is no plan to change this behavior. That
  means that if you are only interested in labels on optional
  arguments, classic mode is already enough.

* The possibility to "omit labels" in classic mode, and to "omit
  optional arguments" in both modes may be confusing. These are
  completely unrelated features: the worst wording would be to say
  "labels on non-optional arguments are optional in classic mode"

* The rules in the P.S. of my previous mail describe a potential new
  version for _classic_ mode. This does not replace label mode.

* From both theory and implementation point of view, classic mode is
  not simpler than label mode. They both share optional arguments,
  which is the most complex part.

Otherwise it seems that we've got a nice array of answers, covering
everything from the die-hard non-labelist (Chris) to the die-hard
labelist (myself).
Sorry for Judicael, but I see no way to satisfy everybody with a single
mode. (You don't expect me to just drop the label mode, and be happy
with classic, no ?)

Yet, I see no strong support for the label features of classic mode:
* decorative labels in interfaces
  (I thought it could be very useful, particularly if one uses
   ocamlbrowser.)
* the ability to write labels in the code, just to increase safety

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.

To keep the discussion open, here is a 3rd alternative, which involves
making label mode the default mode, removing labels from the standard
library (to keep compatibility with ocaml 2, that's paramount), and
keeping a simplified classic mode for those who don't want to hear of
labels at all. 

* Label mode as default, with no labels in the standard library
  This makes moving to label mode very easy, the only needed
  modifications are when using new libraries that have labels.
  For current label mode users, some (partial) compatibility libraries
  would be provided, so that they (I?) don't have to drop all their
  dear(?) labels.
  (I'm mostly concerned with Pervasives, List, Array, String, and Unix)

* The simplified classic mode would simply prohibit writing labels on
  non-optional arguments in function application. You're free to write
  them anywhere else (abstraction or interfaces), but they are simply
  ignored, and never cause a type error.
  Basically that means that the only rule for non-optional parameters is
        (fun ~l:x -> e) v --> e[v/x]
  That makes all the theory simpler, and we recover soundess :-)
  Only problem: it is no longer possible to write everything in the
  intersection of classic and label mode. I generally try to do this
  when I write examples, but this would become impossible with some
  libraries.
  As a result this mode would have to be demoted: documentation is
  written for default mode, and no-label mode users are on their own
  to remove spurious labels.
  Even demoted, label users might still need it for some
  administrative tasks, like adding a labeled interface to a
  non-labeled library.

Would Chris (who doesn't write the labels anyway) be happy with
something like that ?
Would others enjoy moving to label mode at no cost (with libraries
compatible with 2.x) ?
That is, would they be ready to write more labels when they use
labeled libraries (like labltk) ?
Are there some real users of classic mode around (who use what I
called its "label features"), and would they fit in any of these two
categories ?
How much do label users care for having labels in the standard library?

Here are a few more answers to Manuel, whose post was closest to this
proposal:

From: "Manuel Fahndrich" <maf@microsoft.com>

> I use label in classic mode, mostly to disambiguate arguments of the
> same type and a little bit for documentation.

Nice, a real classic mode user!

> To see if I could do with modern mode, I tried to compile my current
> code base with -modern. This seems to not be too bad, except for 2
> things, one being a show stopper:
> 
> 1) The standard library requires ~f: labels on many function arguments.
> That seems silly. I basically had to add ~f: to many places where it did
> not add disambiguation (f is not a very explicit name). I can see that
> for partial applications that might be useful, but still I found this a
> bit annoying.

Not really for partial application (you rarely want to apply to a list
before the function), but rather for layout. Mostly a question of
taste, but if you like it really changes the way you use functionals.

Anyway, if we remove labels from the standard library, this would
solve the problem.
 
> 2) If some library function requires a function argument with labeled
> arguments, such as Map.fold f:(key:key -> data:'a -> 'b -> 'b)
> and I happen to have a function around that would do the right fold
> operation, except that it is unlabeled or has different labels, then I'm
> stuck. I have to write an eta conversion. Why isn't an explicit cast to
> change the labels of a function sound? I tried that and it didn't work.

The notion of soundness being with respect with an untyped reduction
semantics (cf http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/),
changing labels through a cast cannot be sound...

Is it that big a problem in practice ?
I really doubt it: I discussed it with some heavy Haskell users, and
repeatedly got the answer that they don't use fold because this
produces unreadable code. Labels and eta-expansion are just necessary
steps to make it readable.

Anyway, if we remove....
 
> Other than the above, it seems that a casual user like me could move
> from classic to modern, especially if there are some further benefits
> like partial applications in different orders.  One thing that needs
> improvement though are the error messages. Because the compiler tries to
> reorder arguments etc., forgetting a label spits out really whacky
> messages like, this function expects too many arguments.

So, you are rather a frustrated potential label mode user than a happy
classic mode user ?

Cheers,

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