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

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

Salut Xavier,

I'm a bit surprised by your post. Yes this discussion is lively.
But it is calm, and we just try to find the Right Way. I'm not sure it
was the case last year, so I wouldn't discard this discussion as
useless.

> 1- We wanted labeled and optional function arguments to be an
> extension of the Caml language (just like objects, classes, and
> modules to a very large extent), i.e. something that does not affect
> the core ML language, and remain backward compatible with earlier
> versions of OCaml.  I think this is crucial for two reasons.  First,
> it must be possible to learn and teach OCaml incrementally, by
> successive layers of increasing complexity.  Second, we happen to have
> users that develop significant applications in OCaml, and changing the
> language in incompatible ways every other year is a sure way to piss
> them off.  We get enough criticism and suspicion about OCaml "changing
> all the time"...

This doesn't dispense us of trying to find a good solution.
Last year's change was 100% compatible, but I think that during our
discussions before the release we also talked of non 100% compatible
approaches. The real question is to make the cost of transition
neglectible, isn't it? And not to have to change again.

> 2- With the strict label semantics of OLabl or OCaml with the -labels
> option (if a label is given in the function definition/declaration, it
> must be used in all applications of that function), the only way to
> achieve backward compatibility (point 1 above) is to have versions of
> the standard libraries that are totally unlabeled.  Otherwise,
> long-time Caml users would have to change every call to List.map in
> their code, and teachers would have to teach labels very early.
> 
> Of course, having standard libraries completely unlabeled kind of
> defeats the purpose of labels (i.e. self-documentation of library
> functions and additional safety and flexibility at applications of
> these functions), so Jacques' initial proposal was to have two
> versions of the standard libraries, one with labels and one without.
> But we quickly realized this was unfeasible.  It's just too hard to
> maintain two versions of the same libraries.  And everyone who writes
> a Caml library and wants it to be used as widely as possible while
> taking advantage of labels would also need to maintain two versions.

I made some proposals to make the differences small enough that this
would be easy to maintain.
One important trouble yet is where is the limit between standard
libraries and other libraries.

> 3- Thus the "classic mode" was born as a way to have only one
> (labeled) interface to a library, yet not force users of this library
> to use labels at applications.  I really liked this idea of Jacques,
> because we can put labels in the library interface to self-document
> it, yet remain backward compatible with code using the library without
> labels.  Of course, users that want the additional safety of labels
> can provide them at application sites, where they will be checked by
> the type-checker.  To me, this is an excellent compromise: while I
> usually don't put labels at application sites, I enjoy the additional
> documentation provided by labels in module interfaces.

I sincerly hoped this would work.  Unfortunately, I see not very much
enthusiasm for the classic mode.

> 4- Since we did not want to trash the OLabl approach immediately, the
> "commuting label mode" was introduced

Huh, strange view of history.

> A year or so later, I'm still convinced this design is the most
> reasonable approach.  Yes, having two modes is not nice, but it is a
> lot less bad than the alternatives.  If one mode must go, I think it's
> the "commuting label" mode because of the backward compatibility issue
> (point 1) and the fact that multiple versions of the libraries are
> infeasible (point 2). 

I understand perfectly well point 1 (to a certain extent), but I'm not
so sure point 2 is really a problem if we are not too ambitious.

> So, the real questions I have for readers of this list:
> 
> - How many of you use the "commuting labels" mode?
I do. But I don't like votes.
> - For those who use it, do you take advantage of commutation or
>   do you use it mostly to benefit from strict checking of labeled
>   arguments?
Both, of course.
> - What is worse in your opinion: having two modes or removing the
>   "commuting label" mode?
I do not see where this alternative comes from.
Classic mode was designed as an interaction mode with label mode.
I wouldn't consider it very interesting on its own. (That's maybe its
main drawback)

Apologies for the short tempered reaction.

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