Yet more evidence for Wadler's law

Posted Jun 29, 2018 12:53 UTC (Fri) by renox (guest, #23785)
In reply to: Yet more evidence for Wadler's law by HelloWorld
Parent article: PEP 572 and decision-making in Python

> Of course the real problem here is not the discussion but Python's broken language design. John McCarthy figured out in 1958 that the artifical separation of statements and expressions is completely unnecessary, and yet Van Rossum felt it necessary to make that mistake again 40 years later.

That's funny: C's assignment operator being an expression instead of a function is viewed as a source of errors: if (toto = FOO) instead of if (toto == FOO),
which creates ugly things like Yoda speak if (FOO == toto) or the non-standardized (but less ugly) "double parenthesis" pattern.

Yet more evidence for Wadler's law

Posted Jun 29, 2018 13:17 UTC (Fri) by adobriyan (subscriber, #30858) [Link]

It is hard to typo SETF into EQ or =. But it is very easy to typo '==' into "=".

Python has different operators for bitwise and logical operations which C should copy (already copied with iso646.h except if you try to use them, men will stop shaking hands with you).

Yet more evidence for Wadler's law

Posted Jun 29, 2018 13:25 UTC (Fri) by excors (subscriber, #95769) [Link]

Isn't that largely solved by modern compilers producing warnings in that case? (or in Java by making it a compile error, except in the unlikely case that the variable is a boolean). Personally I haven't seen it be a significantly common source of bugs, compared to the dozens of other ways that bugs can be introduced by small syntax errors, so it doesn't seem worth hobbling the whole language just for that.

Yet more evidence for Wadler's law

Posted Jun 29, 2018 14:38 UTC (Fri) by nybble41 (subscriber, #55106) [Link] (11 responses)

> C's assignment operator being an expression instead of a function is viewed as a source of errors

The errors are not due to assignment being an expression rather than a statement. To prevent assignment from being used in a context where a value is expected the result type of an assignment could simply be defined as void, while still treating it as an expression. The real issue, though, is the similarity between '=' and '==' and the fact that '=' is commonly used in math and elsewhere to represent equality, not assignment. Simply changing the names to '=' for equality and something like ':=' for assignment would have eliminated the issue without any change in semantics.

Yet more evidence for Wadler's law

Posted Jun 29, 2018 15:00 UTC (Fri) by renox (guest, #23785) [Link] (1 responses)

> To prevent assignment from being used in a context where a value is expected the result type of an assignment could simply be defined as void,

You're splitting hair, the different between a statement and a function which will return always void..

Yet more evidence for Wadler's law

Posted Jun 29, 2018 17:27 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> You're splitting hair, the different between a statement and a function which will return always void..

The difference is significant in terms of language design. Unification of statements and expressions does not imply that all expressions must produce a value, any more than a function call—which is always considered an expression in C—must produce a value. The point is merely to avoid having two distinct kinds of syntax. Instead of "statements" and "expressions", where statements can include expressions but not vice-versa, you'd simply have "expressions which return a usable value" and "expressions which return void". A function body would just be a single expression to be evaluated.

Add to that treating 'void' as a standard type with exactly one possible value (and thus no runtime representation), suitable for declaring variables, fields, parameters, etc., and some sort of local variable-binding expression similar to LISP's 'let' form, and you enable much more straightforward and expressive generic programming which currently can only be achieved through nonstandard extensions such as GCC's statement-expressions and __builtin_choose_expr() / __builtin_types_compatible_p().

Yet more evidence for Wadler's law

Posted Jun 29, 2018 15:08 UTC (Fri) by anselm (subscriber, #2796) [Link] (8 responses)

Simply changing the names to '=' for equality and something like ':=' for assignment would have eliminated the issue without any change in semantics.

That makes a lot of sense, especially with 20/20 hindsight. It's, however, just as well to remember that when C was invented, the method of choice to talk to your Unix machine (a PDP-11) would have been a 300-baud teletype printer. The original Unix developers were pragmatic people and they wanted to avoid superfluous keystrokes, hence ls and rm instead of list and remove, and, because C programs tend to contain way more assignments than equality comparisons, = for assignment and == for equality. (OTOH, Niklaus Wirth, who invented Pascal at about the same time, was not a pragmatist at all, so Pascal does have := for assignment and = for equality.)

Someone who came up with a new programming language today would probably not think twice about using “←” for assignment, which should eliminate the nasty ambiguity. But the heritage of the 300-baud teletype is still with us today and unlikely to go away anytime soon.

Yet more evidence for Wadler's law

Posted Jun 30, 2018 7:36 UTC (Sat) by HelloWorld (guest, #56129) [Link] (1 responses)

I don't buy that at all. A single additional character per assignment is very unlikely to be a problem, even on a 300-baud tty.

Yet more evidence for Wadler's law

Posted Jun 30, 2018 12:41 UTC (Sat) by anselm (subscriber, #2796) [Link]

The convention of = as the assignment operator and == as the equality operator actually arose when Ken Thompson designed the B programming language, the predecessor of C. B in turn is derived from Martin Richards' programming language, BCPL, which does use := for assignment, but one of Thompson's goals when designing B was apparently “reducing the number of non-whitespace characters in a typical program” [Wikipedia article on B].

Yet more evidence for Wadler's law

Posted Jul 8, 2018 15:12 UTC (Sun) by nix (subscriber, #2304) [Link] (5 responses)

> Someone who came up with a new programming language today would probably not think twice about using “←” for assignment

The lesson of B and Z: if your wonderful new language uses lots of symbols that aren't on people's keyboards, uptake will be slow. (Though editors could translate <- into ←, one wonders why you didn't just use <- in the first place and avoid this probably-nearly-universal difficulty.)

(Mind you, a bigger lesson of B: if you ring-fence a language around with copyrights and everything else you can think of, and allow only one implementation on one platform with no FFI facilities, you can expect not too terribly many people to take it up...)

Yet more evidence for Wadler's law

Posted Jul 13, 2018 0:36 UTC (Fri) by zblaxell (subscriber, #26385) [Link] (2 responses)

> Though editors could translate <- into ←, one wonders why you didn't just use <- in the first place and avoid this probably-nearly-universal difficulty.

Indeed, "←" is M-bM-^FM-^P, which is even worse than "<-" at 300 baud. Adoption would be slow for the first 15 years while the C development community waited for Unicode to be invented.

Yet more evidence for Wadler's law

Posted Jul 13, 2018 6:12 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (1 responses)

It's RightAlt+y on my keyboard layout in Linux (Polish).

Yet more evidence for Wadler's law

Posted Jul 19, 2018 16:52 UTC (Thu) by mina86 (guest, #68442) [Link]

Weird, my Polish layout has ‘ü’ there. ;)

Yet more evidence for Wadler's law

Posted Jul 13, 2018 10:47 UTC (Fri) by nix (subscriber, #2304) [Link]

(Note for clarity: I'm not talking about Thompson's B here, but Abrial's B: <https://en.wikipedia.org/wiki/B-Method>. Whether it was only ever visibly used on French safety-critical systems because it was a formal method, because it was ring-fenced, and had only one implementation, or because like Z it used insane numbers of unprounceable symbols that made it really hard to actually talk about the programs you were writing, I'm not sure. Heck it might just be because it was French and your average Silicon Valley VC doesn't speak much French...)

Yet more evidence for Wadler's law

Posted Jul 13, 2018 19:07 UTC (Fri) by ErikF (subscriber, #118131) [Link]

"<-" has the same problem as the compound assignment operators in early versions of C (i.e. "=+", "=-", etc.): it's ambiguous in high-traffic places. How would you then do a comparison like "a<-b"?

Yet more evidence for Wadler's law

Posted Jun 29, 2018 22:59 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> That's funny: C's assignment operator being an expression instead of a function is viewed as a source of errors: if (toto = FOO) instead of if (toto == FOO)
The problem here isn't that the assignment is an expression but that is has the type of the left operand. If assignment expressions had type void, you couldn't make that mistake.