a = b = 1 just syntactic sugar?

[Ed Avis]

Steven Taschuk <staschuk at telusplanet.net> writes:

>>     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

You're right of course.  I was in the habit of assuming that parens
could be added anywhere to disambiguate, since in language courses at
university, teaching materials used to say at the beginning 'parens can
be used to disambiguate' and then they were not mentioned for the rest
of the course.  But in the real world a programming language's grammar
needs to include ( and ) explicitly.

Still, wouldn't it work to parenthesize the whole lambda-expression to
avoid ambiguity:

    swap = (lambda L,i,j: L[i], L[j] = L[j], L[i])

In this case a parse that took the RHS as a 3-tuple would not be
possible, since the 'L[j] = L[j]' in the middle would be a statement
and statements cannot appear inside tuples.

It's likely that similar 'good fortune' applies to other cases where a
comma might appear and you might worry about it being parsed as a
tuple-forming comma.  If the body of lambda is a one-line statement
(and not an expression_stmt) then this misparse is not possible.

I do, however, need to go back and check this more thoroughly, now
that I realize that parenthesizing the whole lambda function body is
not possible as a quick fix.

>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.

Others said that tuple-forming comma binds much more loosely than
anything else, which suggests that this is not the case.

(Would 'x, 3' be a statement anyway?)

>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.)

If you are right, then this is a serious objection and a good enough
reason to reject the proposal.

However - I have been using the grammar at
<http://python.org/doc/current/ref/grammar.txt>, which seems different
to the file you quote (presumably from the Python source code).  I
think they are different enough to cause confusion, in particular, in
grammar.txt a simple_stmt is not a list of statements and cannot
contain ';'.  Could we continue using that file as reference, unless
you believe that it is incorrect wrt the current Python
implementation, in which case I will switch to Grammar/Grammar instead.

>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).

The point I would like to explore is how significant and how
problematic these changes really are.  You've raised some possible
objections to the grammar production I suggested, and I will check
it.

>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.

Maybe.  OTOH it is probably easier to give a rationale for; easier to
say 'you need bracking here because otherwise...' than to say 'assert
cannot be used in a lambda function because it's a statement, and it
is because it is'.

My feeling is that as long as no existing programs change meaning or
become invalid - as long as only those people who want to write
anonymous functions of one line of code that happens to be an
statement are affected - then the change is worth considering.  This
desired property of 'it doesn't affect you if you don't use it' is not
in itself a reason to add a feature to the language, but it clears the
way for consideration of use cases and the principle of least surprise.

>A working patch would probably convince me;

I'm beginning to think I should write one, I don't know when I will
get around to it though.

>so probably would a thorough analysis of the syntactical issues.

To do that I would need to understand a bit more about how a BNF
grammar is interpreted; how the binding tightness of operators is
decided, whether parsing at each level is greedy, and so on.

-- 
Ed Avis <ed at membled.com>