[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Alternative formulations of keywords
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?
> 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 http://ccil.org/~cowan
that cooks with olive oil, and the part that email@example.com
cooks with butter. -- David Chessler