a = b = 1 just syntactic sugar?

[Ed Avis]

"Terry Reedy" <tjreedy at udel.edu> writes:

>Lambda expressions are syntactic sugar that allow the embedding of
>what would otherwise be a def statement within some other statement

Not quite, of course, since not everything that can appear in a def
statement can appear in a lambda.

[lambda 'designed for side-effect free expressions']

>>I would accept this argument, except for the four examples I
>>mentioned above.  They are all things which have side effects, and
>>which are not excluded from appearing in lambda expressions.
>
>So what?  Many syntactic constructs can be used for more than
>intended or thought about by the designer.

The point is that the supposed justification for lambda's restrictions
- that it is supposed not to have side effects - bears no relation to
how it really behaves.  The extra complexity introduced by having an
arbitrary and semantically meaningless (IMHO) set of rules about what
can be used in lambda and what can't doesn't seem worthwhile.

>'Having side-effects' is not a grammatical category and could not
>practically be part of a syntactic rule for lambda.

I agree.  (Although some languages do make a meaningful distinction
between expressions and statements so that expressions cannot have
side effects.)

Why then not allow the same things inside lambda as inside def?  At
least as far as keeping the function body on a single line.

>Extending lambda to embed even simple statements within expressions
>is problematical:

    lambda x: assert(x > 0)
    lambda x: print 'value:', x
    lambda x: y += x    # (without any change to scoping rules)

I don't see what is so problematical about any of these.  And they are
all things you might reasonably want to use as lambda expressions (for
example an assertion that 'every number in this list is positive').

Then again, I am not a Python developer.  Perhaps there is some
syntactic ambiguity that would stop the above examples being
parsable.  But it seems unlikely, one of the big advantages of Python
is is clean grammar (currently marred only by the strange rules about
lambda-expressions, IMHO).

>>    condition and if_branch or else_branch

>This conditional selection expression (which I have used) works as a
>substitute for part of certain if-else statements if and only if
>bool(if_expression) == True, which is often true or can be chosen to
>be true.

If you are referring to short-circuiting evaluation, point taken.  I
suppose it would be better to have real if-else inside anonymous
functions (more consistent with the rest of the language, certainly).

-- 
Ed Avis <ed at membled.com>