A replacement for lambda

[Christopher Subich]

Mike Meyer wrote:
> My choice for the non-name token is "@". It's already got magic
> powers, so we'll give it more rather than introducing another token
> with magic powers, as the lesser of two evils.

Doesn't work.  The crux of your change isn't introducing a meaning to @ 
(and honestly, I prefer _), it's that you change the 'define block' from 
a compound_stmt (funcdef) (see 
www.python.org/doc/current/ref/compound.html) to an expression_stmt 
(expresion).  This change would allow some really damn weird things, like:

if def _(x,y):
       return x**2 - y**2
(5,-5): # ?!  How would you immediately call this 'lambda-like'?[1]
    print 'true'
else:
    print 'false'

[1] -- yes, it's generally stupid to, but I'm just pointing out what has 
to be possible.

Additionally, Python's indenting Just Doesn't Work Like That; mandating 
an indent "after where the def came on the previous line" (as you do in 
your example, I don't know if you intend for it to hold in your actual 
syntax) wouldn't parse right -- the tokenizer generates INDENT and 
DEDENT tokens for whitespace, as I understand it.

My personal favourite is to replace "lambda" entirely with an 
"expression comprehension", using < and > delimeters.  It just looks 
like our existing list and generator comprehensions, and it doesn't use 
'lambda' terminology which will confuse any newcomer to Python that has 
experience in Lisp (at least it did me).

g = <x**2 with (x)>
g(1) == 1

Basically, I'd rewrite the Python grammar such that:
lambda_form ::= "<" expression "with" parameter_list ">"

Biggest change is that parameter_list is no longer optional, so 
zero-argument expr-comps would be written as <expr with ()>, which makes 
a bit more sense than <expr with>.

Since "<" and ">" aren't ambiguous inside the "expression" state, this 
shouldn't make the grammar ambiguous.  The "with" magic word does 
conflict with PEP-343 (semantically, not syntactically), so "for" might 
be appropriate if less precise in meaning.