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.