Email list hosting service & mailing list manager


Re: Alternative formulations of keywords Marc Feeley 12 Apr 2006 04:19 UTC

On 11-Apr-06, at 10:54 PM, John Cowan wrote:

> Marc Feeley scripsit:
>
>> But doesn't this require that all named parameters be supplied?  So
>> it does not help with named optional parameters.
>
> No, it merely requires the existence of a run-time object that
> uniquely represents "unsupplied value".
>
>> The error checking is also very poor.
>
> I don't understand this point.

Then I clearly misunderstand your proposals.  Can you explain your
proposals in more detail?  What I think you are saying in your first
proposal is that keywords are entirely handled at compile time.  The
compiler sorts the keywords and transforms the call into one with
required parameters and positional optional parameters.  So

    (foo 'bar foo: 32 bar: 54)   becomes   (foo 'bar 54 32)
    (foo 'bar xyz: 32 abc: 54)   becomes   (foo 'bar 54 32)   no
error detected?
    (foo 'bar bar: 54)           becomes   (foo 'bar 54)
    (foo 'bar foo: 32)           becomes   (foo 'bar 32)
    (foo 'bar)                   becomes   (foo 'bar)

How is foo going to determine which parameters were supplied?  Are
you assuming that the compiler has some knowledge about foo so that
it knows the complete set of named optional parameters and can pass
the "unsupplied value" for the parameters that are not supplied?  In
general this is impossible because the function to call may be
computed, as in:

    ((f x) 'bar foo: 32 bar: 54)

(f x) might return foo sometimes and at other times a function that
accepts additional named optional parameters.

For the second proposal you have to assume the general case where you
are passing computed expressions, such as:

    (foo 'bar foo: (f x) bar: (g x))

which would have to be transformed into

    (foo 'bar (list (cons 'foo: (f x)) (cons 'bar: (g x))))

Is this correct?

Marc