[Python-ideas] Statements vs Expressions... why?

[Cliff Wells]

On Sat, 2008-09-13 at 12:27 -0700, Bruce Leban wrote:
> 
> 
> On Sat, Sep 13, 2008 at 9:02 AM, Cliff Wells <cliff at develix.com>
> wrote:
>         Let's use your example from above: a+b vs add(a, b)
>         
>         
>         a + b is the *exact* semantical equivalent of add(a, b).  They
>         do the
>         same thing, they can be used in the same contexts.  The +
>         operator is
>         pure semantic sugar (and well-used sugar too).
> 
> 
> First, + is *syntactic* sugar not semantic sugar. Syntactic sugar is
> something that changes the appearance but not the semantics.

Sorry, clearly typing too fast.  I meant semantic the first time I used
it and syntactic the second.

> C uses semicolons and Python doesn't.

Python does, but only as a substitute for a newline.

>  Is that syntactic sugar? Can I just ask C to remove the "restriction"
> that semicolons are required without defining precisely what that
> means? 

Arguably you'd end up with what Python does now.  I think that's
well-enough defined (C's for-loop being an exception, obviously).

> If I do, then I end up with something like Javascript's semicolon rule
> which is confusing and error-prone. No thanks.

I'm not aware of JavaScript's semicolon rule.  When I write JS I use it
as a line-terminator.

>         Now let's imagine things aren't quite so equivalent.  a+b has
>         the same
>         result as add(a, b), except you can only use the + operator in
>         one
>         particular context: assignment. It cannot be used say, with a
>         comparison
>         operator.
>         
>         So in my imaginary Python, this is legal
>         
>          x = 1 + 2
>         
>         but this is not
>         
>          if x < y + 1: pass
>         
>         and must instead be written
>         
>          if x < add(y, 1): pass
> 
> 
> This is a strawman. You hypothesize that + would only be usable in the
> context of "assignment". But that's not the context. The context is
> expression. The semantics are the same.

I was attempting to use Adam's example (which I would have labeled a
strawman, except I don't believe it was intentional) in order to convey
the difference between what he was saying and what I was saying.  If it
fails, well, it's not the example I would have chosen, but I felt it
might help Adam and I find common ground for debating on, so <shrug>.

> Here's a real example: consider a language where +, *, etc. can only
> be used in the context of augmented assignment. That is:
>     a += b
>     c *= d
> etc. while I have to use functional syntax everywhere else:
>     x = add(a,b)
>     y = mul(c,d)
> etc. Now I propose improving this language by eliminating the
> "restriction" that +, * etc. can only be used in assignments.

Actually, this is the strawman.  If you read back (yes, I'm asking a
lot) you'll note that I asserted that statements are (or could be)
semantically equivalent to expressions except they have a limited
context.   Any statement can be made into an expression (but not the
reverse).  T

> You ask me to define the syntax and semantics of these operators and I
> brush that off as unimportant. All I'm advocating is "lifting a
> restriction" in the language. I'm unifying syntax not adding
> complexity, right? No need to explain pesky details.
> 
> 
> No. That's ridiculous. You might be surprised when you use my new
> features that
>     x = 2 * 3 + 4
>     y = 2 - 3 + 4
> sets x to 14 and y to -5 but that's not my fault. (And lest you say
> this is a strawman and no one would consider any value other than 10
> and 3, go look at http://tinyurl.com/27ttcy.)

It's a matter of defining ambiguity.  APL does it by being strictly
left-to-right and Python (and most other languages) defines it by a
(admittedly more complicated) algebraic order of operations.   

> This is what you're doing. If you can't precisely define how the
> language is different with your proposed change, then it's not worth
> discussing. You can do that with a formal definition as I suggested or
> by actually implementing your changes as Guido suggested. 

I think providing examples is enough for a general discussion of the
idea.  Further, if anyone were really curious beyond just discussing it
in the abstract, they could try Logix (although you'll unfortunately
need to have Python 2.4 to do so).

I understand that any such change would need to be adequately defined.
But I don't consider the discussion to have progressed to that point.
If people do not even understand that expression-oriented languages
provide any advantage (in fact, many of them apparently consider it a
disadvantage), then there's little point in discussing what particular
syntax this apparently useless change would take on.

> You can't do it by insisting that no one understands what you're
> talking about.

When someone suggests that the distinction between expressions and
statements is syntactic sugar on the same level as the + operator, then
I have no choice but to assume they really don't understand what I'm
talking about.  Whether that's a failing on my part or theirs is an open
question, but there's no doubt about the lack of understanding.

Anyway, to be frank, once I discovered that the developer of Logix had
moved to Ruby, I finally admitted to myself that I was being completely
unreasonable in expecting Python to be any more than what it is.  I've
already made up my mind to move to a language I find more suitable.  

Regards,
Cliff