a = b = 1 just syntactic sugar?

[Terry Reedy]

"Ed Avis" <ed at membled.com> wrote in message
news:l17k7yjg5a.fsf at budvar.future-i.net...

> Yes... what we are talking about here, of course, is purely syntax.

According to long ago posts and other writings and interviews, when
GvR designed Python, he was quite aware of 'everything is an
expression' languages, whose existence proves that 'statements' are
not a syntactic necessity, and of the syntactical purity/homogeneity
of 'only expressions'.  He consciously choose the heterogenous mixture
of statements and expression as being more conducive to his goal of
readability, especially for beginners.  I believe this choice was
partly based on some experiments that were part of the projects he
worked on previously.  He was also, as I already reported, aware that
in some cases, the choice of statement versus expression for a
particular function was somewhat arbitrary in that there are tradeoffs
for either choice.

In any case, once he choose to have two syntaxes (statement vs
expression) for program functions and once the choice was made for
each, the difference became fundamental for Python's syntactical
design.  Expressions, but not statements, are used in assignment
statements, operator expressions, conditions, function calls,
collection indexing, and, yes, also in lambdas.  Making a singular
exception for lambdas would definitely complexify the language.
Someone who does like the statement/expression design should perhaps
learn one of the all-expression languages instead.

> Semantically there doesn't seem much difference between defining f
> that contains a print statement, and defining an anonymous function
> that has the same.

As I previously said, the only semantic difference between a lambda
and an equivalent def is the definition name.  Lambda is redundant
syntactic sugar for converting a restricted subset of defs to an
expression for syntactic convenience.  (Similarly, print is a
redundant convenience that condenses a restricted subset of
file.write() expressions by doing autoconversion and autoformatting.)

> If a clear and simple syntax can be worked out to

This is a big if.  No one that I know of has yet done so of in years
of discussion.

> let expressions appear in lambda-defined functions,

I presume you meant 'statement' rather that 'expression'.

> just as they can in ordinary functions, there doesn't seem to be
> any other reason to  prohibit it.

Yes there is.  It goes against Python's syntactic design and would
make a singular exception for lambdas (see above).  If substitutivity
were general, then Python would be quite different from what it is.

>  I think that the rule of 'anything that fits on one line'  is such
a simple rule

Simple?  'line' is not a syntactic category.  Do you mean physical
line (if so, any limit in length?) or logical line (same question)?
In either case, you are proposing a new syntactic category of
'pseudoline'.  Would you allow them to contain multiple statements,
separated by ';', like real lines?  If so, how do you indicate that
the scope of the first ';' starts not at the beginning of the real
line but the beginning of the pseudoline defined by some (which)
preceding lambda?  Could a line have multiple pseudolines, defined by
multiple lambdas, such as are now legal?  If so, how do you delimit
them and differentiate between sequential and nested pseudolines?
This is a lot of potential new complexity.

Expressions recursively nest within expressions, with () used as
needed to indicate the nesting.  Statements separate into simple
statements and compound statements, with the latter having bodies
consisting of nested statements (of either subtype) as indicated by
indents.  Sequential statements have same indent, nested statements
have additional indent.

>just as simple as 'any expression, but not a statement' and more
powerful.

To my mind, lambda is already too powerful in that it facilitates
writing obscure, very 'unPythonic' code.  Multiple nested lambda
substitute widely separated and hard to visually match '(' and ')'
pairs for easy to see indents as indicators of control structure.
Much of the obscurity come from having multiple nested local scopes
within one line.

So if we are to make special syntactic rules for lambda, I would like
to make them less powerful by restricting the expression body to
lambda-less expressions.  I think there is a grammatical category for
this so it might be easily possible.  This would be a compromise,
between keeping them as they are and removing them altogether, that
would still allow intended usage but restrict obscuration.

Terry J. Reedy