🚀 go-pugleaf

Just my 2pf worth in the offside-rule/concrete-syntax discussion:

Since concrete-syntax and parsing are "solved problems" :-)
I am attempting to formally prove properties about a scanner and
parser for a subset of OCCAM, a language using the offside rule.

You would not believe the amount of effort needed to prove that the
simple algorithm of counting spaces works properly! The problem is
always in "going back", i.e. reducing the indentation level. One must
prove that the algorithm doesn't go back past 0, etc. This property
makes the algorithm "non-compositional" : you can take 2 properly
indented pieces of code that are syntactically legal, and after
concatenating them get an indented piece of code that is not legal.

The continuation algorithm for occam is unpleasant : one may only
use a new line after a binary operator (because we know that something
else must be coming...) or after certain keywords, and the indentation
can be *more* but not less that the previous line. 

Comments have to be indented at least as much as the *following* line,
and what do you do with blank lines and tab characters and on and on.

For the folks that feel this is context-free for a fixed k : have you
ever written out the LR(80) tables for such a grammar? Theoretically,
one can write a nice van Wijngaarden grammar (aka two-level grammar) that
has an infinite number of members of the token class "level parenthesis",
but unfortunately I have found no efficient way of transforming such
a grammar into code except by LL methods. 

As others have said: why on earth would one introduce so much muck
just to save a keystroke? Belonging to the Ann-Landers-School of
if-you-turned-it-on-turn-it-off-if-you-opened-it-shut-it, I like
the clarity of proper begins and ends. But then I am just a Lisp
hacker which explains a lot.

Debbie Weber-Wulff
FU Berlin
weberwu@fubinf.uucp