[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Alternative formulations of keywords

This page is part of the web mail archives of SRFI 89 from before July 7th, 2015. The new archives for SRFI 89 are here. Eventually, the entire history will be moved there, including any new messages.



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