4 ms·

Is it really worth allowing assignment in places so weird that you also need ==? Wouldn't it be easier to use = for everything and get rid of those weird edge

by mavhc 9y ago

Is it really worth allowing assignment in places so weird that you also need ==? Wouldn't it be easier to use = for everything and get rid of those weird edge cases?

walshemj 9y ago
Or you know use different operators entirely
nfoz 9y ago
Yeah I was pretty surprised when I found out that assignment and equality can be totally syntactically separate and nonambiguous with miminal language-design effort. Just get rid of the silly idea of allowing expressions as statements. Although even then it's nice to use different symbols because they are different meanings. I don't like it when a word has different meanings depending on context.
- icebraining 9y ago
  Just get rid of the silly idea of allowing expressions as statements. I don't think that's enough. Take the two following Python lines: a = b = c == d a = b == c == d No expression is being used as a statement, yet you can't syntactically separate assignment from equality.
  - 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.
  - tom_mellior 9y ago
    I would write these as a = b = (c == d) and a = (b == c == d) respectively. And I think it would make sense to have a syntax rule that strictly enforces parentheses around truthy expressions used in such contexts.
    - icebraining 9y ago
      Right, but then you're using the parentheses to distinguish the assignment from the comparison, it's not just a matter of not allowing expressions as statements.
emodendroket 9y ago
I mean it has plenty of utility.
cup-of-tea 9y ago
It does lead to some pretty neat and idiomatic C, if only they just picked a different symbol for assignment.
ben509 9y ago
I think using arrows would be nicer, especially for complex destructuring / pattern matching, and you arrows are incredibly clear. A complex destructuring case would be something like this: {cashMoney -> foo, stuff: {powerLevel -> bar} <- {cashMoney: 5000, stuff: {powerLevel: 8999}} I think the arrows nicely indicate where data is flowing, and it's unambiguous what is a variable name and what is a field name.
white-flame 9y ago
It is extremely useful for all statements to be able to be used as expressions, to chain and nest values. It's purely syntactic clumsiness on the part of those language families that assignment and comparison are so close to the notion of "equals".
aap_ 9y ago
You want PL/1
lmm 9y ago
Using = for everything still has the problem that "x is always and forever this value" looks exactly the same as "y is this value for now but will be a different value in the future" or "give z, which previously had a different value, this new value". These are three different things and should have different syntaxes; = is appropriate for the first (and using it for that is not incompatible with using it for equality comparison) but not for the second or third.

by mavhc 9y ago

Is it really worth allowing assignment in places so weird that you also need ==? Wouldn't it be easier to use = for everything and get rid of those weird edge cases?

walshemj 9y ago

Or you know use different operators entirely

nfoz 9y ago

Yeah I was pretty surprised when I found out that assignment and equality can be totally syntactically separate and nonambiguous with miminal language-design effort. Just get rid of the silly idea of allowing expressions as statements. Although even then it's nice to use different symbols because they are different meanings. I don't like it when a word has different meanings depending on context.

icebraining 9y ago
Just get rid of the silly idea of allowing expressions as statements. I don't think that's enough. Take the two following Python lines: a = b = c == d a = b == c == d No expression is being used as a statement, yet you can't syntactically separate assignment from equality.
- 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.
- tom_mellior 9y ago
  I would write these as a = b = (c == d) and a = (b == c == d) respectively. And I think it would make sense to have a syntax rule that strictly enforces parentheses around truthy expressions used in such contexts.
  - icebraining 9y ago
    Right, but then you're using the parentheses to distinguish the assignment from the comparison, it's not just a matter of not allowing expressions as statements.

emodendroket 9y ago

I mean it has plenty of utility.

cup-of-tea 9y ago

It does lead to some pretty neat and idiomatic C, if only they just picked a different symbol for assignment.

ben509 9y ago

I think using arrows would be nicer, especially for complex destructuring / pattern matching, and you arrows are incredibly clear. A complex destructuring case would be something like this: {cashMoney -> foo, stuff: {powerLevel -> bar} <- {cashMoney: 5000, stuff: {powerLevel: 8999}} I think the arrows nicely indicate where data is flowing, and it's unambiguous what is a variable name and what is a field name.

white-flame 9y ago

It is extremely useful for all statements to be able to be used as expressions, to chain and nest values. It's purely syntactic clumsiness on the part of those language families that assignment and comparison are so close to the notion of "equals".

aap_ 9y ago

You want PL/1

lmm 9y ago

Using = for everything still has the problem that "x is always and forever this value" looks exactly the same as "y is this value for now but will be a different value in the future" or "give z, which previously had a different value, this new value". These are three different things and should have different syntaxes; = is appropriate for the first (and using it for that is not incompatible with using it for equality comparison) but not for the second or third.