This page is part of the web mail archives of SRFI 88 from before July 7th, 2015. The new archives for SRFI 88 contain all messages, not just those from before July 7th, 2015.
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 firstname.lastname@example.org cooks with butter. -- David Chessler