Re: Syntax for label, NEW SOLUTION

From: John Max Skaller (skaller@maxtal.com.au)
Date: Wed Mar 22 2000 - 00:29:17 MET

  • Next message: Markus Mottl: "Re: to have labels or not"

    Jacques Garrigue wrote:

    > 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.

            I do not: in the short term, two modes is a good compromise.
    In the longer term, one language is better. I am glad for the two
    modes at present. I hope they will go away in the future.

    > > o The fact that you've had to resort to "modes" at all indicates something
    > > is wrong.

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

            I agree. Particularly, I was attracted by some of the
    olabl software but was not willing to use two compilers. Now I have
    the nice olabl software, and still have my ocaml software too.
     
    > > 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.

            Sure, why not?

    > I already explained a while ago why it was not possible to have labels
    > both optionals and commuting in a curried language.

            Sure it is. The question is whether the error messages
    are readable. Python supports

            1) positional arguments
            2) labelled arguments
            3) default values for missing trailing positional parameters
            4) optional labelled AND positional arguments

    It does not support currying, but it does diagnose missing arguments,
    and such could be re-implemented as partial applications.

            FYI the rules are: for a definition:

            def f(x,y,z=1,q=2,*args, **kwds): ...

    and calls

            f(1,2)
            f(1,2,3,4,5,6,7)
            f(1,z=6,y=4, extra=22)

            1) bind parameters to the given positional arguments positionally.
            If there are too many, the extra ones go into the tuple 'args' if
    given,
            else error.

            2) try to bind the remaining positional arguments from labelled ones.
            If there is a duplication of labelled and positional arguments, error.
            If there are still missing required arguments,
                    then use the default if there is one,
                    else error (change to 'curry' for our purposes)

            3) if **kwds is given,
                    put all the labelled arguments into dictionary kwds (even those
                    used to fill in required arguments)

            4) if there are excess labelled arguments and no kwds, then error.

    Thousands of Python programmers use this scheme every day.
    Currying missing arguments would disable error checking,
    so in Python you have to use a separate function definition.

    [This could actually be fixed by sugar: use f(x, curry) to signify
    intentional currying]

            I'm not suggesting to use thd Python scheme, only that
    it _is_ possible to support optional commuting labelled arguments
    and optional arguments, and default arguments, and variable
    length argument lists and arbitrary option sets coherently.

    > Do not confuse the fact of having two reasonably consitent modes with
    > having only one in which any strange thing is allowed.

            Also do not confuse 'we cannot think of a synthesis of the
    modes which makes sense' with 'there exists no such synthesis' :-)
     
    > 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

            Why not allow several (synonymous) labels?

            let f c: chr: character: the_really_verbose_character: c' = c'

    -- 
    John (Max) Skaller, mailto:skaller@maxtal.com.au
    10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
    checkout Vyper http://Vyper.sourceforge.net
    download Interscript http://Interscript.sourceforge.net
    



    This archive was generated by hypermail 2b29 : Wed Mar 22 2000 - 17:14:49 MET