Re: Syntax for label, NEW SOLUTION

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

Since I do not want to flood the caml-list with messages, I answer
several messages together.  This makes the answer a bit long, but bear
with me if you are interested.

From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>

> First to clarify, there are two distinct problems with labels:
> 
> - Their syntax: Anything that let me put (or not put) spaces where I
> want will suit me. (If people are not happy with the final syntax let
> them use camlp4 :-)

That's not easy, but maybe we can find something.
After your idea of keeping `:' in types, and only change the syntax
for terms, I first thought that this would be bad, in particular this
would cause technical problems in the lexer, since we do not want a
special lexing rule for `:' anymore. However if we decide that
labels cannot have keyword names, this should be possible to work it
out at the parser level (the :label form is no longer needed).

As Xavier included `\' in his list (which surprised me a little, since
for me '\' was taboo), I would go for it.

That is, replace ':' by '\' in terms, but keep ':' in types.
Any counter-proposals?

> - Their semantics in modern mode.
> 
> I quite agree, their should not be two modes, because this will means
> two communities of users and therefore at some point two standards
> libraries because each kind of users will have different needs. This is
> dangerous ...
> soon there would not be only one big caml community anymore.

There is a misunderstanding here.  There are currently two
communities, and one goal of the merger is to have a big caml
community again.  I think that having two modes is a good way to reach
this goal.  All this discussion just shows that this would be very
difficult with only one mode.

> But there may be a solution in three step:
> 
> 1) Let's have only the modern mode. But let it accept any expressions
> with no amibiguities. This means that if according to both types AND
> labels there is a unique valid order of arguments then the compiler do
> not complain.
> 
> At this point you can use blit with
> 
> > Array.blit a src_pos:x b dst_pos:y len
> 
> If both array a and b have not the same types and
> 
> > Array.blit src:a src_pos:x b dst_pos:y len
> 
> If they have the same type.
> 
> This is reasonnable ! 

I do not understand very well your proposal.  If you let arguments
commute when there is no ambiguity, then this is just a big mess,
because the concept of no ambiguity is only understood by the
compiler. If you do not let them commute, then I do not see how this
improves on classic mode, which already allows you to check labels
when you want.

> 3) For the problem of List.fold_left (+), there is a solution: tell to
> the compiler that (+) is commutative ! Or more generally find a syntax
> to tell that two or more arguments of the same types may be commuted
> without changing the behaviour of the function. Then there would be no
> ambiguities when you type List.fold_left (+) and the compiler wii not
> complain ! There would be a problem only with  List.fold_left (/) but
> then writing the labels explicitely may be better (or rewrite it with a
> product).

Woa. Teaching properties of functions to the compiler would be very
nice, but I'm afraid type checking technology is not nearly mature
enough for that. That's a good subject for research :-)

From: Don Syme <dsyme@microsoft.com>

> I really don't see people clamouring for lots of labels in the standard
> library (besides the inventors of the language feature, who don't really
> count, for lots of obvious reasons - over exposure to the feature, over
> familiarity with the label names, a natural bent to program in a particular
> way that led them to the feature in the first place, self-selection as
> people who think the feature is the best thing ever).

Maybe they're just decent, and do not like flame wars.
I do not like either, and have to force myself to write these messages.
I can only tell you that ocaml-2.99 has a few labels less that olabl,
and that I already had comments from olabl users who thought it was "odd".
There were also several messages in this forum insisting for then fun:
label on functionals, and this is the function fold_right which
started all this discussion.

> o The fact that you've had to resort to "modes" at all indicates something
> is wrong.  The point about O'Caml is that you shouldn't have to understand
> _anything_ about labels, objects, modules or syntax modes to use the system
> as a new user.  You shouldn't have to see any labels, nor have to ask "what
> are these two modes all about", nor have to try to understand why some of
> the arguments have labels and some don't.

Well, before that there were two compilers.  I think this is a progress.

> o The "just documentation" response doesn't really hold water, because if
> the labels were just documentation, then they would different.  For example,
> "fun", being a keyword, is highly confusing and not terribly descriptive -
> any sensible prototype would probably just use "f".  And C prototypes look
> _horrible_ when you have both higher order arguments and argument names.

If you think that some labels are not that good as documentation, then
make suggestions.  Since most people will only use them as
doumentation, this should be a priority.  And if they are good
documentation, then will certainly be good to use in programs also.
The problem about C prototypes and higher-order functions is really a
problem with the way you write function types in C, not about the
variable names.

From: John Prevost <prevost@maya.com>

> If we could come up with a semantics where labels are always optional,
> I think I would accept things like acc in the standard library.  But
> when you have to make a choice between optional labels and no useful
> functionality, it's a harder sell.

Some people really want to eat the cake and still have it.
I already explained a while ago why it was not possible to have labels
both optionals and commuting in a curried language.
Even if it were possible, I would fully agree with Pierre on this
point: this is going to make programs unreadable.  If you do not
decide clearly which is your policy, then you end up with Perl!
Do not confuse the fact of having two reasonably consitent modes with
having only one in which any strange thing is allowed.

From: Damien Doligez <Damien.Doligez@inria.fr>

> I agree, and I would even go further.  I think the current labeling of
> the standard library is way too verbose.  "fun" should not be "func"
> or even "fn", but simply "f".  That's the usual name for a generic
> function.  Likewise, we should replace char:char with c:char and so
> on (maybe even the predicate function in List.for_all should be
> labeled f).
> 
> Also, in the List module, I found this:
> 
>     val nth : 'a list -> pos:int -> 'a
> 
> This is really bad design, unless the goal is to confuse the reader
> (two different names for the same number).  It should be either
> 
>     val nth : 'a list -> n:int -> 'a
> 
> or
> 
>     val posth : 'a list -> pos:int -> 'a
> .
> 
> I think we need to develop a systematic set of abbreviations (and a
> document to explain it) that will allow us to limit almost all labels
> to be at most one character in length.  It would (at least partially)
> solve the problem of expression cluttering that we have with the long
> labels currently in the library.  As a side-effect, it would also
> solve the problem of keywords as labels: there isn't any keyword of
> length 1.

That sounds reasonable. I would also personally prefer "f:" to "fn:".
My choice of labels has been driven by voices from olabl users who
insisted that labels should be as readable as possible, but having
short names is ok if they are readable.  Still I would not support
reducing _all_ labels to 1 character, while it might be ok for most
of them in the standard library.  Having a document for it is only
bearable as long as it is standard

The choice of pos: rather than n: in List.nth was driven by an attempt
at homogeneizing labels with other modules, in which pos: is used.
But too much homogeneity is not always good.  If the meaning does not
exactly match, then it might be better to use another label.

Remark that if we are going to do such extensive changes, we must have
a coordination to choose labels, and that it will take some time.

> This is an excellent suggestion, and I have implemented it (as of
> version 2.99+12) : I replaced the command-line option "-modern" with
> "-label".  I kept "-modern" as an alias to "-label" for the time
> being, but I certainly hope we'll retire it before we release 3.00.

You're a bit fast Damien. Personally I would really prefer -commute.
Labels are also available in classic mode, it is just that they do not
commute there.

Also a very personal comment: why do you persist in erasing the date
from the version number? I really think it helps to trace back
problems :-)

Best regards to everybody,

Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>