Discussion of P4P language syntax

P4P is an alternate syntax for Racket, a descendant of PLT Scheme. The Lisp-derived S-expression syntax is notoriously inaccessible to the uninitiated, and there have been many attempts to devise equivalents which demand less mental decoding. This one is noteworthy because the author’s prose is clear and reasoning sensible; there are some interesting points which apply to syntax design in general. Specifics that caught my eye:

Racket has a excellent language design, a great implementation, a superb programming environment, and terrific tools. Mainstream adoption will, however, always be curtailed by the syntax. Racket could benefit from liposuction, stomach stapling, or just plain getting off the couch and getting out for a ride, to reduce the layers of parenthetical adipose that – as this document argues, needlessly – engird it. P4P is a proposal for how to do this without losing the essential nature of the Lisp syntactic heritage (and, indeed, bringing to the surface the streaming nature that has always been hidden within).

I increasingly view emphasizing good indentation as critical. In some languages, however, indentation controls semantics. I view this as a mistake.

In P4P, instead, the semantics controls indentation: that is, each construct has indentation rules, and the parser enforces them. However, changing the indentation of a term either leaves the program’s meaning unchanged or results in a syntax error; it cannot change the meaning of the program. I believe this delivers the advantages of enforced indentation while curbing its worst excesses.

P4P does not have any optional syntax. I believe this makes it easier to teach people to program: they want clear instructions, not “You can do this, or you can do that…you can do whatever you want!” (If they were ready to do whatever they wanted, they wouldn’t be asking you.) These trade-offs are best left to semantic and design levels, not syntax.

I suppose I like this essay in no small part because the author’s preferences agree with mine. It is a careful, regular transliteration of syntax only, with no semantic consequences, and thus its value exists solely in the realm of aesthetics. I care a lot about aesthetics, so this looks like a good thing to me.

Radian takes the same attitude toward indentation, incidentally: instead of using indentation to drive structure, as in Python, the compiler uses structure to validate indentation. The result is similar, in that one’s programs must always be indented correctly, but the meaning comes from the code and not the whitespace. Among other things this means that automatic reindentation is possible.

File I/O functions

Today’s checkin adds a pair of io functions, one to read and one to write the contents of a file. There’s also a new file module in the library which abstracts a file path.

import file from radian
var foo = file.from_path( "/some/path/here" )

The file module contains only the from_path constructor and a type? predicate; the file interface itself requires only a path property. This abstraction is overkill at the moment; I'm struggling between "you ain't gonna need it" and the sense that retrofitting this in later would make a mess of the API.

read_file(file, continuation)

An IO continuation, as I discussed before, is a programlet which receives as its parameters a new IO object and some value. In this case, the value is a buffer containing the contents of the specified file. A buffer is just a sequence of bytes, which is to say numbers in the range 0..255.

write_file(file, data)

The corresponding write operation replaces the contents of the file with the contents of the data, which must also be a sequence of bytes. The file's new length will be equal to the sequence's length.

After implementing this I realize that write_file needs a continuation parameter, too; otherwise there is no way to find out whether the write operation succeeded, or to sequence any further activities which depend on the existence and contents of the file.

Structure of a Ruby gem