because in math it means assignment. y = mx+b That is an assignment. There is also a math symbol that specifically designates equivalence.
But if = in math notation denoted "assignment", what could ≠ mean?
51–60 of 367 posts
because in math it means assignment. y = mx+b That is an assignment. There is also a math symbol that specifically designates equivalence.
But if = in math notation denoted "assignment", what could ≠ mean?
Because K&R had terrible keyboards so they abbreviated everything as much as possible. Traditionally := was used for assignment, which makes sense since it is an asymmetric symbol for an asymmetric operation.
Traditionally? I don't think there was a "tradition". ":=" was used in Algol. "=" was used in Fortran. COBOL didn't use either "=" or ":=".
Plankalkül for example was out a decade earlier and used →. EX:
P1 max3 (V0[:8.0],V1[:8.0],V2[:8.0]) → R0[:8.0]
https://en.wikipedia.org/wiki/Plankalk%C3%BClSo, there really was a lot of languages out there, but := was fairly common because it was easy to parse and type.
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?
because in math it means assignment. y = mx+b That is an assignment. There is also a math symbol that specifically designates equivalence.
Another interesting way to think about it is as "match". That is try to match the stuff on the right with the stuff on the left. Take Erlang for example: 1> X = 1. 1 2> X = 2. ** exception error: no match of right hand side value 2 Notice variables are immutable (not just values themselves). Once X becomes 1, it can only match with 1 after that. You might think this is silly or annoying, why not just allow reassignme…
I'm sure I've mentioned it here before, but in my favorite Erlang talk I design the language with the equal sign as my core construct. Since the equal sign is an assertion of truth, and since assertions cause a crash on failure, you can pretty much derive the rest of the language/BEAM characteristics from that.
Earlier quoted context omitted.
I'm sure I've mentioned it here before, but in my favorite Erlang talk I design the language with the equal sign as my core construct. Since the equal sign is an assertion of truth, and since assertions cause a crash on failure, you can pretty much derive the rest of the language/BEAM characteristics from that.
I don't think I've heard of this before; I'd love to watch it if you have a link!
Earlier quoted context omitted.
Ditto. Fun fact: various dialects of BASIC let you optionally put LET before your assignment statements. So the following are equivalent: X = 10 LET X = 10
Wait...LET was optional? Auigh! Whole months of my childhood, wasted!
As someone who learned first on a ZX81, I'd always assumed that "LET X=5" was the canonical form, and that "X=5" for assignment was just a shortening for convenience.