[bitc-dev] Layout-like rules for BitC

[Jonathan S. Shapiro]

So I've been thinking about layout rules for BitC, and I've consequently
been looking at them in Haskell a bit harder. I was going to ask why the
Haskell "Layout" rules were not applied after "in", but looking at the
grammar, I think I was getting confused by SML's expression sequences. In
SML:

let decl in exp1 ; ...; expn end

provides sequencing. Is there an analogous syntax in Haskell? Given that
Haskell is a lazy language, I suspect the answer is "do", but I'ld
appreciate confirmation.

Ironically, the fact that the decls in "let *decls* in ..." is fully
bracketed by tokens already, so the *only* reason to put the curly braces
there is to enable the layout rules to work. The brackets aren't needed
there at all; only the semicolons.


In BitC, we have several block-like contexts where we would like something
like the layout rules to apply, and they seem to divide into two categories:
type declarations and blocks. At the moment, in all contexts where
semicolons appear in the grammar, they are optional. This is the main thing
that conflicts with curried application. When semicolons are optional and no
Layout rule exists, something like "f 1 3" and

f 1
3

are indistinguishable. In fact, there's also a problem with "f(1)", which
the current grammar "solves" by shifting explicitly in this case.

If we decide to switch to using something like a layout rule, it would be
pleasant if the brackets and semicolons could be optional in:

struct S('a, 'b) {
  a: 'a;
  b: 'b;
}

at the moment, the semicolons are optional here, but the brackets are
mandatory. We could add a keyword to signal the layout rule, as in:

struct S('a, 'b) *is *{
  a: 'a;
  b: 'b;
}

or we could adapt the layout trick such that the column alignment is
performed on the struct keyword. If that can be made to work, I think that I
prefer it, because it also works for things like:

while(testExpr){
  e1;
  e2;
}

What do people think of possibly using that approach? It requires somewhat
tighter integration between the parser and the lexer, but it's certainly
doable.

There are some subtle difference between this and the Haskell Layout
behavior:

   - For semicolon and closing curly insertion purposes, the indent indent
   column is set to the indent column of the lexeme following the (possibly
   inserted) curly brace, *provided* that indentation is greater than some
   defined anchor token - in this case the "while" keyword.
   - Automated semicolon insertion occurs whether the curly brace is
   inserted by hand or not - or is this a bad idea?
   - In order to make this work, all left curly braces in the grammar must
   be preceded by a non-categorical lexeme so that we have an apropriate left
   context on the parse stack to support the "optional left curly" reduction.

>From the standpoint of Unicode, I think this will work okay in practice as
long as the programming style tends to place the anchor keyword as the first
non-space keyword in a line.

But I really have to ask here - has *anybody* managed to build a workable
emacs-mode for Haskell? If I have to give up my editor, you can all take a
jump on the Layout rules. After all, the only real reason to write code in
the first place is to exercise the emacs-lisp engine. Stops it from getting
flabby.:-)


shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100809/1671d047/attachment.html