List comprehension confusion...

[Kaz Kylheku]

Lulu of the Lotus-Eaters <mertz at gnosis.cx> wrote in message news:<mailman.1044215405.21615.python-list at python.org>...
> Ah...  I think you haven't quite "got" the gestalt switch yet, Peter.
> The reason I use lambdas at all is BECAUSE of the lack of return
> statment... that helps express a concept.  Here's an explanation that I
> hope might help:
> 
> A *pure* function is simply a type of mapping between a domain and a
> range.  In mathematics, it is no problem to express infinite domains and
> ranges (or just large ones); but in programs it is often convenient to
> express a calculable relationship algorithmically rather than
> statically.

Doh, haven't you ever heard of lambda calculus? Where do you think the
term ``lambda'' comes from? It's the greek letter used in the notation
of lambda calculus to denote the place where the name of an anonymous
function would be written, if it had one.

Lambda calculus is a form of *mathematics* that expresses a calculable
relationship algorithmically (using recursion).

In LC, functions are treated as mathematical objects which can be
represented by variable names, and passed as arguments to other
functions. To express this in a notation, it becomes mandatory to
separate the function itself, its body and argument list, from the
name. This lets you write literal functions, just like nameless
numbers, sets, vectors, matrices and other objects.

  The thing to understand is that these are not fundamentally
> different creatures, just different conveniences.  For example, compare:
> 
>     _2xdict = {1:2, 2:4, 3:6}
>     _2xfunc = lambda i: i*2
>     print _2xdict[2]
>     print _2xfunc(2)

In a real programming language, an anonymous function has the full
power of an ordinary named function.

Your arguments about purity are ill-conceived; you are arguing that
some kind of semantic purity is supported by the impurity of an
idiotic syntax which prevents you from having the same expressivity in
a lambda as in a regular function.

The tool you are using gets the job done. To you it represents some
good tradeoff between portability, performance, expressivity, platform
access and other factors. That's all the rationale you need.

You don't have to sacrifice the purity of your thought by defending
its inherent idiocies with irrational arguments.

It's extremely useful to have closures that can do anything which any
other functions can do. It's not a beneficial feature that there is
only one expression allowed, and hence no return statement. It is
simply a braindamaged limitation, and one that doesn't exist in some
other languages that have lexical closures.