On Nov 6, 2019, at 08:59, Chris Angelico <rosuav@gmail.com> wrote:
No, because "x <-- y" is already legal syntax (it applies unary minus to y twice, then checks whether x is less than the result).
You could handle that by making the grammar more complicated. I don’t think it’s a good idea at all, but I think it could be done. Without working through the details, I think all you’d need is a rule that the assignment statement production is tried before the expression production. This would mean that any statement made up of a result-ignoring less-than comparison between an expression simple enough to be a target and a double-negated expression can only be written by putting a space after the < symbol, but that probably affects not a single line of code ever written. But (even assuming I’m right about that), it would mean a new and unique rule that you have to internalize to parse Python in your head, or you’ll stumble every time you see <-. And I don’t think people would internalize it. A big part of the reason Python is readable is that its grammar is simple (compared to anything but Lisp or Smalltalk), and usually obviously unambiguous, to humans, not just to parser programs. Not that Python doesn’t already have a few rules that people don’t completely internalize. (I don’t know exactly the rules for when you can leave parens off a genexpr, a yield, maybe even a tuple; I only know them well enough to write code without pausing, and to read 99.99% of the code anyone writes without pausing, and there probably are constructions that would be legal if anyone ever wrote them that would momentarily throw me for a loop.) But in each case, the advantage is so huge (imagine having to write `x, y = (y, x)` everywhere…) that it’s clearly worth it. In this case, the advantage would be tiny (instead of having to learn that assignment is spelled :=, as in many other languages and non-code contexts, I get to learn that assignment is spelled <—, as in many other languages as non-code contexts?). So it’s definitely not worth it.