[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?

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            http://ccil.org/~cowan
that cooks with olive oil, and the part that            cowan@ccil.org
cooks with butter. -- David Chessler