Re: Syntax for label, NEW PROPOSAL

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

I include a proposal at the end, please comment if you feel concerned.

From: Don Syme <dsyme@microsoft.com>

> And why not "as", i.e. "t as x", as I explained once in a previous post.
> I never did get an explanation as to why this wasn't an better solution.  It
> reuses a rarely-used keyword in a perfectly backward-compatible way.  
> I think it's simply a typical case of a new (and not necessarily terribly 
> crucial) language feature muscling in on the limited "ultra-convenient" 
> concrete syntax that's available!   No offence intended ;-)

An none taken.

Seriously, I believe the decision for the syntax of labels has be done
on a number of bases, including ideas collected on the caml list (sorry
if we didn't give feedback for every proposition).

Basically the strongest criteria were

1) comfort. Call it crucial or not, in typical modern mode code you
   have several labels by line of code. Anything more than one
   character is going to be heavy. Remember that ML is this wonderful
   language in which application is expressed by 0 characters!

2) inertia. Objective Label has been around for several years already
   (in fact, just as long as Objective Caml), and users seemed to be
   satisfied with the syntax.

3) homogeneity. The only change has been in the syntax for default
   parameters, which is a bit more homogeneous now. The idea was from John
   Prevost.

From: Christophe Raffalli [mailto:Christophe.Raffalli@univ-savoie.fr]
> It is clear that labels are a good thing ...
> But why did you use the same character ":" for types and labels !
> 
> whit not (for instance) x:t to say that x as type t
> and                     l#x to say that x as label l


Our conclusion on that point was that spaces are significant, and
there is no real ambiguity. You have to put spaces around : in type
annotations.

Also, the superficial similarity is in fact good in some cases:

	val sub : string -> pos:int -> len:int -> string

Argument types here "look like" type annotations.

> the syntax l#x:t is much better than l:x : t !!

Well, you do not write the above directly. Here are real cases:

(t type of the result)
	let f l#x:t = ...
	let f l:x : t = ...
(t type of the argument)
	let f (l#x:t) = ...
	let f (l: x : t) = ...

Do you really think that not putting spaces enhances readability?
And that once you have put the spaces, it is still hard to read?

If you do, then it might mean that our choice was wrong.

*** Proposal

Objective Caml 3.00 is not yet released, and I believe we can still
have modifications on this point.

Here is an alternative proposal, to use `%' in place of `:'. Labels
are kept as a lexical entity. This still breaks some programs, since
`%' was registered as infix, but this is not so bad.

In this case, I suppose we should read `%' as `is'.

Pro:
* `%' reminds a bit of substitution, which is the intuitive role of
  labels in applications.
* I checked it on a reasonable corpus of code, and it is
  readable enough. Particularly -shumacher-clean-* looks nice.
* changes to the compiler are very small.

Con:
* I still think that `:' looks better, particularly inside types.
* On my keyboard I can type in `:' without pressing shift :-)
* We will need some tool to convert existing code.

Do you think it would be better?
Are there people around who would rather keep `:' ?

Examples:

        Objective Caml version 2.99+10

# List.map;;
- : fun%('a -> 'b) -> 'a list -> 'b list = <fun>
# List.map [1;2;3] fun%succ;;
- : int list = [2; 3; 4]
# let sub ?(%pos = 0) ?%len s =
    let len = match len with Some x -> x | None -> String.length s - pos in
    String.sub %pos %len s;;
val sub : ?pos%int -> ?len%int -> string -> string = <fun>

Regards,

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