Email list hosting service & mailing list manager

Re: complexity of mechanism felix winkelmann (12 Apr 2006 19:39 UTC)
Re: complexity of mechanism Eli Barzilay (12 Apr 2006 20:54 UTC)
Re: complexity of mechanism felix winkelmann (13 Apr 2006 06:43 UTC)
Re: complexity of mechanism Eli Barzilay (13 Apr 2006 07:07 UTC)
Re: complexity of mechanism felix winkelmann (13 Apr 2006 08:04 UTC)
Re: complexity of mechanism Eli Barzilay (13 Apr 2006 08:26 UTC)
Re: complexity of mechanism felix winkelmann (13 Apr 2006 09:44 UTC)
Re: complexity of mechanism John Cowan (13 Apr 2006 11:43 UTC)
Re: complexity of mechanism John Cowan (13 Apr 2006 11:52 UTC)
Re: complexity of mechanism Eli Barzilay (13 Apr 2006 12:58 UTC)
Re: complexity of mechanism felix winkelmann (13 Apr 2006 13:15 UTC)
Re: complexity of mechanism Eli Barzilay (13 Apr 2006 13:07 UTC)
Re: complexity of mechanism feeley (13 Apr 2006 14:07 UTC)

Re: complexity of mechanism feeley 13 Apr 2006 14:08 UTC

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