3 ms·

I think GP might have meant that to go the other way around, i.e. don't allow statements to also be expressions, and more specifically, make assignment a statem

I think GP might have meant that to go the other way around, i.e. don't allow statements to also be expressions, and more specifically, make assignment a statement.

nfoz 9y ago
Well first I was super intriguied by the example. But I agree with your conclusion, that statements should not also be expressions, so a = b = c shouldn't work (at least not the way we're used to, that the b = c is an assignment "statement" that also produces an expression value). But in the end all this does is allow "a = b = c" to be a nonambiguous statement meaning, in more familiar notation, "a = b == c". Not exactly clear! So even though a language could use the same symbol for both assignment and equality-check, I don't recommend it! Although I still like to keep statements and expressions as strictly non-interchangeable constructs.
- mavhc 9y ago
  What I've not seen is examples of needing to distinguish between assign and compare, that outweigh the added complexity. if x=y # obviously compare x=y # obviously assignment x=y=z # is that really needed? If so, brackets
- boomlinde 9y ago
  Just noting that I didn't mean to express any particular preference for syntax, just addressing whether it's technically possible. Personally I'm fine with = vs == being prevalent, but might prefer something like := and = respectively.
icebraining 9y ago
No, Python assignments are not expressions. "a = b = c" is just an assignment statement with multiple parts, it's not equivalent to "a = (b = c)", which in fact will throw a SyntaxError.
- boomlinde 9y ago
  Implementing this typically means making substantial changes to a language that doesn't already have it, or implementing a new language. In such a language, having a special multiple assignment syntax based on trains of = and variable names would obviously be impractical.

3 ms·

I think GP might have meant that to go the other way around, i.e. don't allow statements to also be expressions, and more specifically, make assignment a statem

by boomlinde 9y ago

I think GP might have meant that to go the other way around, i.e. don't allow statements to also be expressions, and more specifically, make assignment a statement.

nfoz 9y ago
Well first I was super intriguied by the example. But I agree with your conclusion, that statements should not also be expressions, so a = b = c shouldn't work (at least not the way we're used to, that the b = c is an assignment "statement" that also produces an expression value). But in the end all this does is allow "a = b = c" to be a nonambiguous statement meaning, in more familiar notation, "a = b == c". Not exactly clear! So even though a language could use the same symbol for both assignment and equality-check, I don't recommend it! Although I still like to keep statements and expressions as strictly non-interchangeable constructs.
- mavhc 9y ago
  What I've not seen is examples of needing to distinguish between assign and compare, that outweigh the added complexity. if x=y # obviously compare x=y # obviously assignment x=y=z # is that really needed? If so, brackets
- boomlinde 9y ago
  Just noting that I didn't mean to express any particular preference for syntax, just addressing whether it's technically possible. Personally I'm fine with = vs == being prevalent, but might prefer something like := and = respectively.
icebraining 9y ago
No, Python assignments are not expressions. "a = b = c" is just an assignment statement with multiple parts, it's not equivalent to "a = (b = c)", which in fact will throw a SyntaxError.
- boomlinde 9y ago
  Implementing this typically means making substantial changes to a language that doesn't already have it, or implementing a new language. In such a language, having a special multiple assignment syntax based on trains of = and variable names would obviously be impractical.