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

[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...

[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.