a = b = 1 just syntactic sugar?

[Steven Taschuk]

Quoth Ed Avis:
> Steven Taschuk <staschuk at telusplanet.net> writes:
> 
> >    swap = lambda L,i,j: L[i], L[j] = L[j], L[i]
> 
> As I mentioned elsewhere on this thread, lambda-functions could be
> parenthesized where this is necessary.  The proposed change to have
> one-line statements instead of expressions inside lambda would not
> (AFAIK) make any parse that is currently unambiguous require
> parentheses; only some new cases such as your example with commas
> would need it.  So
> 
>     swap = lambda L,i,j: (L[i], L[j] = L[j], L[i])

Note that this does not match your proposed syntax

    lambda_form ::= "lambda" [parameter_list]: simple_stmt

since assignment statements may not be parenthesized.

Also, although I know next to nothing about the parser
implementation, I'd think it parses simple_stmt greedily.  If that
is so, the change you propose would break the parsing of
    lambda x: x, 3
since the whole "x, 3" would be greedily consumed as a
simple_stmt.  (I'm just guessing, of course, but at least in a
half-educated way; note in Grammar/Grammar that the present rule
for lambda
    lambdef: 'lambda' [varargslist] ':' test
uses 'test', while simple_stmt
    simple_stmt: small_stmt (';' small_stmt)* [';'] NEWLINE
    small_stmt: expr_stmt | print_stmt | [...]
    expr_stmt: testlist (augassign testlist | ('=' testlist)*)
uses 'testlist', which is
    testlist: test (',' test)* [',']
.  I'd think this would affect the handling of commas in lambdas
in a backwards-incompatible way.)

> > [...] Anonymity is a red
> >herring; so are closures; the important point is that lambdas are
> >expressions and defs are statements.
> 
> Well a named function has two halves: the 'def f: ...' which is a
> statement, and the use of the name 'f' which is an expression.  Lambda
> combines both in one place.  [...]

I do not find this a useful way to describe the situation.  That a
name bound to an object (whether by def statement or otherwise)
can be used in an expression tells us nothing about the syntax for
creating the object, nor about the object itself.  You can do the
same with a lambda-created function, after all:
    foo = lambda x: 2*x    # create function object, bind name 'foo' to it
    print foo(3)           # use 'foo' in expression
or, indeed, any object whatsoever.

The point under discussion is the function-creating text; for
lambdas that is an expression, and for defs it is a statement.  I
regret that you think it's harping, but ultimately that's why
lambda is restricted to expressions -- being an expression itself,
it may only contain expressions (barring significant and, imho,
likely-to-be-problematic changes to the grammar).

> [...] Letting it contain one-line statements
> seems like the best compromise between the two worlds.  Expressions
> only is too counterintuitive IMHO.

I disagree, as I'm sure you've realized by now.  Certainly I don't
expect allowing statements in expressions to work out well -- even
if restricted to simple_stmt, and even with parentheses.  For
example, the circumstances under which you'd need parentheses seem
much more complicated to explain than the difference between
expressions and statements.

But I'm willing to be convinced otherwise.  A working patch would
probably convince me; so probably would a thorough analysis of the
syntactical issues.

Once I'm convinced it's feasible, I might reject it on aesthetic
grounds, of course.  :)

-- 
Steven Taschuk                            staschuk at telusplanet.net
"Our analysis begins with two outrageous benchmarks."
  -- "Implementation strategies for continuations", Clinger et al.