Spelling reform is pointless

[fanf]

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.

Comments

[ewx.livejournal.com]

Also, C's "->" should be spelled ".".

[ewx.livejournal.com]

Oh, in fact you sort-of mentioned that. But it's superfluous anyway even if you don't reform the indirection operator.

[fluffymormegil.livejournal.com]

I like the idea of prefix '@' as the indirection operator.

[pm215]

That would fit with my usual pronuncistion of pointer-deref '*' in C, which is "whatever's at"...

[zkzkz.livejournal.com]

a) Ok, you have me convinced regarding ~
b) You messed up the signal() declaration so that's a good sign you need a better syntax. And the fact that I can't tell you how to fix it tells me I might need one too :)
c) I don't understand why you say > is utter nonsense on boolean values. What's nonsense about it?

[zkzkz.livejournal.com]

Hum, no, my apologies, your declaration for signal is correct.



cdecl> explain void (*signal(int, void (*)(int)))(int);

declare signal as function (int, pointer to function (int) returning void) returning pointer to function (int) returning void

[simont]

Actually it was someone at Trinity, not at school, but that's a minor point.

Applying comparison operators to booleans: there is one situation in which it's almost useful. If you adopt the BBC BASIC convention of having TRUE denoted by -1 instead of +1, then the expression A <= B, which looks to mathematicians as if it ought to be an implication, actually is one :-)

As it happens, when I recently needed to design a throwaway expression grammar, I actually did write it so that comparison operators chained as you specify (including ensuring that each subexpression was only evaluated once, although since no expressions in my language have side effects that was only an efficiency consideration rather than an important semantic point). Another unusual thing I did was to give the boolean logic operators AND, OR and XOR the same precedence but forbid distinct logical operators from associating. So a AND b AND c is fine, and so is a OR b OR c, but a AND b OR c is a syntax error.

[covertmusic.livejournal.com]

Now, I'm definitely no language lawyer, but looking over my own code here, there's very few occasions where I use a for loop without actually wanting some kind of vector op over the output of an iterator/collection;

foreach element in iterator
do
analysis(element)
done

which, of course, is the map/reduce pattern, isn't it? As long as analysis is side-effect free, anyway. I could rewrite the vast majority of it as map(analysis, iterator).

(As an aside, that's given me an idea for something I'm working on, which with hindsight should have been obvious. More of that on my work blog soon, maybe...)

It strikes me you don't actually need an arithmetic for at all: if you've got a language with lazily-evaluated iterators (like Python 2's xrange and Python 3's range), then they're just foreach over the domain of the iterator. Any good reason not to generalise that far?

Variously, though, I program in languages with no arithmetic for loop (Python), no real loops at all (XSLT), or with exactly one rather rubbish looping construct (Fortran 90's do loops), though, so I probably have a rather skewed perspective...

[vatine]

How about ( 4 > 3 > 2 ), an expression that (ideally) expresses "four is larger than three is larger than two" and, on the whole, is true. If we start from the left, use 0 for false and 1 for true, we find ourselves with ( 1 > 2 ) and this is, alas, obviously not true.

It's easy in infix and I believe there've been languages where teh syntax for relational exables follow closer to mathematical notation.

[fanf]

It's nonsense to compare a boolean with a number or a string. I'm not talking exclusively about C, which doesn't have a proper boolean type.

[fanf]

The main reason for having a counting for as well as an iterator for is efficiency, especially in scripting languages that don't do the kind of compile-time analysis that can optimise away the closure allocation and function calls.

In Lua the for varlist in explist do loop can be used in two ways. The pure way is for the explist to evaluate to a closure that is called to generate a new list of values each time round the loop; the closure encapsulates the iterator's state. Alternatively, the explist can evaluate to a triple of function, fixed value (e.g. the table to iterate over), and initial variable value (e.g. a cursor into the data structure), so that the same function can be used to iterate over any object without having to allocate a closure to perform the loop. A little less elegance for a little more efficiency.

[fanf]

The problem is that indirection is a prefix operator; the spelling is incidental. All the other operators that do something useful are postfix operators - () [] . - which is what makes the syntax so bad.

[sparrowsion]

Python chains comparisons in exactly the way you want. Which trips up people who are stupid enough to write if x == y is True: ….