Email list hosting service & mailing list manager

Re: Alternative formulations of keywords John Cowan 12 Apr 2006 02:54 UTC

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.

> BTW: Who is forcer?

Jorgen Schaefer.

> Are you saying that the programmer writes
>      (foo 'bar foo: 32 bar: 54)
> and the compiler transforms this to
>      (foo 'bar (list (cons 'foo: 32) (cons 'bar: 54)))

No, to a literal, not a run-time constructor.

> This seems to be an implementation of named optional parameters, so
> it is unclear to me what you are criticizing in the specification of
> the SRFI.  However I should say that a compile time handling of
> keywords will not work in general.  Think of:
>      (foo 'bar (f 11) 32 (b 22) 54)
> where f returns foo: and b returns bar: .  A general implementation
> of SRFI 89 must parse the list of parameters at run time because some
> of the keywords may be computed.

What are the use cases for computed keywords?

All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part  
that cooks with olive oil, and the part that  
cooks with butter. -- David Chessler