## Spelling reform is pointless

#### « previous entry | next entry »

** 23rd Jun 2007 | 13:55**

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

We getvoid(*signal(intsig,void(*func)(int)))(int);

voidsignal(intsig,voidfunc^(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 **simont**atham'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:

forinit<=var<limitdo...forinit>=var>limitdo...forinit<=var<=limitdo...forinit>=var>=limitdo...forinit<=var<limitbystepdo...forinit>=var>limitbystepdo...forinit<=var<=limitbystepdo...forinit>=var>=limitbystepdo...

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

from:ewxdate:23rd Jun 2007 14:46 (UTC)Permalink

->" should be spelled ".".## Reply | Thread

from:ewxdate:23rd Jun 2007 14:47 (UTC)Permalink

## Reply | Parent | Thread

from:fluffymormegildate:23rd Jun 2007 19:24 (UTC)Permalink

## Reply | Thread

from:pm215date:23rd Jun 2007 20:58 (UTC)Permalink

## Reply | Parent | Thread

from:fanfdate:25th Jun 2007 08:09 (UTC)Permalink

## Reply | Parent | Thread

from:zkzkzdate:23rd Jun 2007 21:31 (UTC)Permalink

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?

## Reply | Thread

from:zkzkzdate:23rd Jun 2007 21:45 (UTC)Permalink

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

## Reply | Parent | Thread

from:vatinedate:24th Jun 2007 09:13 (UTC)Permalink

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

## Reply | Parent | Thread

from:fanfdate:24th Jun 2007 15:28 (UTC)Permalink

## Reply | Parent | Thread

from:simontdate:23rd Jun 2007 22:44 (UTC)Permalink

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 forbiddistinctlogical 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.## Reply | Thread

from:covertmusicdate:24th Jun 2007 00:45 (UTC)Permalink

forloop without actually wanting some kind of vector op over the output of an iterator/collection;foreachelementiniteratordoanalysis(element)

donewhich, of course, is the map/reduce pattern, isn't it? As long as

analysisis side-effect free, anyway. I could rewrite the vast majority of it asmap(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

forat all: if you've got a language with lazily-evaluated iterators (like Python 2'sxrangeand Python 3'srange), then they're justforeachover 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

doloops), though, so I probably have a rather skewed perspective...## Reply | Thread

from:fanfdate:24th Jun 2007 15:39 (UTC)Permalink

foras well as an iteratorforis 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

forvarlistinexplistdoloop can be used in two ways. The pure way is for theexplistto 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, theexplistcan 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.## Reply | Parent | Thread

from:sion_adate:25th Jun 2007 10:55 (UTC)Permalink

`if x == y is True: …`

.## Reply | Thread