Re: A critic of Guido's blog on Python's lambda

2006-05-07 Thread Patrick May
[EMAIL PROTECTED] (Alex Martelli) writes:
> In my opinion (and that of several others), the best way for Python to
> grow in this regard would be to _lose_ lambda altogether, since named
> functions are preferable

 Why?  I find the ability to create unnamed functions on the fly
to be a significant benefit when coding in Common Lisp.

Regards,

Patrick


S P Engineering, Inc.| The experts in large scale distributed OO
 | systems design and implementation.
  [EMAIL PROTECTED]| (C++, Java, Common Lisp, Jini, CORBA, UML)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: A critic of Guido's blog on Python's lambda

2006-05-07 Thread Patrick May
[EMAIL PROTECTED] (Alex Martelli) writes:
>> >> In my opinion (and that of several others), the best way for
>> >> Python to grow in this regard would be to _lose_ lambda
>> >> altogether, since named functions are preferable
>> >
>> >  Why?  I find the ability to create unnamed functions on the
>> > fly to be a significant benefit when coding in Common Lisp.
>> 
>> 1. They don't add anything new to the language semantically
>>i.e. you can always used a named function to accomplish the same
>>task as an unnamed one.

 Sure, but it won't necessarily be as expressive or as convenient.

>> 2. Giving a function a name acts as documentation (and a named
>>function is more likely to be explicitly documented than an
>>unnamed one). This argument is pragmatic rather than
>>theoretical.

 Using lambda in an expression communicates the fact that it will
be used only in the scope of that expression.  Another benefit is that
declaration at the point of use means that all necessary context is
available without having to look elsewhere.  Those are two pragmatic
benefits.

>> 3. It adds another construction to the language.

 That's a very minimal cost relative to the benefits.

 You haven't made your case for named functions being preferable.

Regards,

Patrick


S P Engineering, Inc.| The experts in large scale distributed OO
 | systems design and implementation.
  [EMAIL PROTECTED]| (C++, Java, Common Lisp, Jini, CORBA, UML)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: A critic of Guido's blog on Python's lambda

2006-05-08 Thread Patrick May
[EMAIL PROTECTED] (Alex Martelli) writes:
> ...an alleged reply to me, which in fact quotes (and responds to)
> only to statements by Brian, without mentioning Brian...
>
> Mr May, it seems that you're badly confused regarding Usenet's
> quoting conventions.

 It seems that someone pisses in your cornflakes nearly every
morning.

 For the record, I was attempting to respond to your post which I
only saw quoted in another message.  Please excuse any accidental
misquoting.

>>  Using lambda in an expression communicates the fact that it
>> will be used only in the scope of that expression.  Another benefit
>> is that declaration at the point of use means that all necessary
>> context is available without having to look elsewhere.  Those are
>> two pragmatic benefits.
>
> You still need to look a little bit upwards to the "point of use",
> almost invariably, to see what's bound to which names -- so, you DO
> "have to look elsewhere", nullifying this alleged benefit -- looking at
> the def statement, immediately before the "point of use", is really no
> pragmatic cost when you have to go further up to get the context for all
> other names used (are they arguments of this function, variables from a
> lexically-containing outer function, assigned somewhere...), which is
> almost always.

 It appears that you write much longer functions than I generally
do.  Requiring that all functions be named adds even more to the
clutter.

> And if you think it's an important pragmatic advantage to limit
> "potential scope" drastically, nothing stops you from wrapping
> functions just for that purpose around your intended scope

 Or, I could just use a language that supports unnamed functions.

> Your "pragmatic benefits", if such they were, would also apply to the
> issue of "magic numbers",

 That claim is, frankly, silly.  A function is far more
understandable without a name than a value like 1.19 in isolation.
The situations aren't remotely comparable.

>> >> 3. It adds another construction to the language.
>> 
>>  That's a very minimal cost relative to the benefits.
>
> To my view of thinking, offering multiple semantically equivalent
> ways (or, perhaps worse, "nearly equivalent but with subtle
> differences" ones) to perform identical tasks is a *HUGE* conceptual
> cost: I like languages that are and stay SMALL and SIMPLE.

 Like Scheme?

Regards,

Patrick


S P Engineering, Inc.| The experts in large scale distributed OO
 | systems design and implementation.
  [EMAIL PROTECTED]| (C++, Java, Common Lisp, Jini, CORBA, UML)
-- 
http://mail.python.org/mailman/listinfo/python-list