Re: Syntax for label, NEW PROPOSAL

From: Jacques Garrigue (garrigue@kurims.kyoto-u.ac.jp)
Date: Wed Mar 15 2000 - 04:15:49 MET

  • Next message: Christophe Raffalli: "Re: Syntax for label, NEW PROPOSAL"

    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>



    This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 08:51:23 MET