This page is part of the web mail archives of SRFI 89 from before July 7th, 2015. The new archives for SRFI 89 contain all messages, not just those from before July 7th, 2015.
On 13-Apr-06, at 9:06 AM, Eli Barzilay wrote:
On Apr 13, felix winkelmann wrote:[...] (and a subsequent overcomplication of lamba-list processing).Marc -- one relevant comment about the srfi: it seems like many negative gut reactions to this srfi are because you used `lambda' instead of a new name. It might help if you revise it to use a different name. (If there's a good enough module system in place, then it doesn't matter anyway, since you can have a module that will provide the new-lambda as `lambda'.)
I haven't seen any comments to that effect on the list, and I don't understand the motivation. There is no overhead in a lambda form that supports optional parameters in the cases where this feature is not used (i.e. lambdas with only required and rest parameters). Check the reference implementation. The only difficulty is getting at the "low-level" lambda form, which can't be done portably (I'd like to be proven wrong... Oleg are you listening?). But this is no problem for the implementor of the Scheme system, or if you have access to the source code. In PLT you can probably use something like #%lambda .
Given this fact it would be a real wart to have two forms in a language where one subsumes the other in every detail (except for the name). You start off using "lambda" (or "define") when you design a function, and then when you add an optional parameter you have to switch to "lambda-opt" (or "define-opt"). That's not very friendly. This can be transparent, so why not make it so?
Marc