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

[Bill Atkins]

aleaxit at yahoo.com (Alex Martelli) writes:

> Bill Atkins <NOatkinwSPAM at rpi.edu> wrote:
>    ...
>> > ``allow ( as an ordinary single-character identifier'' as for the
>> > unneded feature ``allow unnamed functions with all the flexibility of
>> > named ones''.
>> 
>> Not so infeasible:
>> 
>>   (let ((|bizarrely(named()symbol| 3))
>>      (+ |bizarrely(named()symbol| 4))
>> 
>>    ;; => 7
>
> Read again what I wrote: I very specifically said "ordinary
> *single-character* identifier" (as opposed to "one of many characters
> inside a multi-character identifier").  Why do you think I said
> otherwise, when you just quoted what I had written?  (Even just a
> _leading_ ( at the start of an identifier may be problematic -- and just
> as trivial as having to give names to functions, of course, see below).

Well, the same technique can obviously be used for:

 (let ((|(| 3)))
   (+ |(| 4)))
 ;; => 7

The length of the identifier is irrelevant...

>> And in any case, enforced indentation is a policy with vastly more
>> serious consequences than the naming of identifiers.
>
> So far, what was being discussed here isn't -- having to use an
> identifier for an object, rather than keeping it anonymous -- trivial.
> Python practically enforces names for several kinds of objects, such as
> classes and modules as well as functions ("practically" because you CAN
> call new.function(...), type(...), etc, where the name is still there
> but might e.g. be empty -- not a very practical alternative, though) --
> so what?  Can you have an unnamed macro in Lisp?  Is being "forced" to
> name it a "serious consequence"?  Pah.

Common Lisp does not support unnamed macros (how would these be
useful?), but nothing stops me from adding these.  What use case do
you envision for anonymous macros?

> Anyway, I repeat: *any* design choice (in a language, or for that matter
> any other artefact) has consequences.  As Paul Graham quotes and
> supports his unnamed friend as saying, Python lets you easily write code
> that *looks* good, and, as Graham argues, that's an important issue --
> and, please note, a crucial consequence of using significant
> indentation.  Alien whitespace eating nanoviruses are no more of a worry
> than alien parentheses eating nanoviruses, after all.

It *is* an important issue, but it's also a subjective issue.  I find
Lisp to be far prettier than any syntax-based language, so it's far
from an objective truth that Python code often looks good - or even at
all.

Plus, I can easily write code that looks good without using a language
that enforces indentation rules.  Lisp's regular syntax lets Emacs do
it for me with a simple C-M-a C-M-q.  What could be easier?

>
>
> Alex

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan