.@ Tony Finch – blog


Here are some of my favourite pointless suggestions for syntactic changes to programming languages.

Bitwise not and exclusive or

By analogy with negation and subtraction, I think the operators for not and xor should be spelled the same. I.e. instead of a ^ b write a ~ b.

Indirection

Prefix * in C is disastrous for both expression and declaration syntax. Pascal's postfix ^ for indirection is much more sensible. Fortunately the previous reform frees up ^ in C for this purpose. We can then abolish -> since it becomes superfluous.

Instead of

    void (*signal(int sig, void (*func)(int)))(int);
We get
    void signal(int sig, void func^(int))^(int);

Associativity of relational operators

It doesn't make sense for relational operators to be associative. To specify that in a > b > c the first comparison gives a boolean result that is compared with c is utter nonsense. It's much more sensible to say that relational operators chain as in mathematical notation, so that expr relop expr relop expr ... expr relop expr is equivalent to expr relop expr and expr relop expr and ... and expr relop expr except that each expr is evaluated at most once. BCPL has this syntax except for the latter guarantee, so you can't say ’0’<=rdch()<=’9’ which is a shame.

Precedence of logical not

Logical not or ! should have precedence between logical and / && and the relational operators, so that there's much less need for an unless keyword.

Counting with for loops

The Modula (etc.) style for var = init to limit by step do ... is too wordy. The C style for (var = init; var < limit; var += step) ... is too generic and too repetitive. Lua's for var = init, limit, step do ... is way too cryptic. I quite like an idea from one of 👤simontatham's school friends, which fits in nicely with chained relational operators and mathematical notation. It comes in a few variants, for counting up or down, with exclusive or inclusive limits, with unity or non-unity step:

    for init <= var < limit do...
    for init >= var > limit do...
    for init <= var <= limit do...
    for init >= var >= limit do...
    for init <= var < limit by step do...
    for init >= var > limit by step do...
    for init <= var <= limit by step do...
    for init >= var >= limit by step do...

Assignment and equality

I'm a firm believer in shunning bare = as an operator, and using := for assignment and == for testing equality - at least in languages where assignment is an expression. There's much less opportunity for confusion in languages where assignment is a statement and therefore if var = expr then ... is a syntax error. Since I have a head full of Lua at the moment I will note that it has one place where assignment and equality can clash, in table constructor expressions, where the former is key/value construction and the latter is list-style construction with a boolean value.