[bitc-dev] Bracketing conventions
Jonathan S. Shapiro
shap at eros-os.org
Thu Apr 1 10:51:57 PDT 2010
BitC is trying to straddle the imperative/functional boundary, and
(not surprisingly) this raises some conflicts of style. Broadly
speaking (with the notable exception of Scala), functional languages
have been more or less in the pascal-like camp:
let x = expr IN body-expr or let x = expr IN body-expr END
vs. C/C#/Java style, which is (as a historical matter) designed as a
statement syntax:
{ def x = expr; body-expr; }
Viewed purely from an expressiveness perspective, there isn't that
much difference. The one substantive issue is that C/C#/Java don't
have a distinction between LET and LETREC, so they seem to get away
with mixing bindings and statements freely.
My current inclination is that ';' should be a statement/expression
terminator in BitC, and that sequences of expressions should be
wrapped by curly braces. So:
LET x = expr IN expr;
LET x = expr IN { e1; e2; }
and not
LET x = expr IN e1 END
LET x = expr IN e1; e2 END
The reason to prefer strong bracketing (whether through braces or
keywords) is disambiguating the parse, and particularly the
interactive parse.
Do people have a strong preference? If we're going to attract the C
community, braces seem like the better way to go.
For the record, I do recognize the sheer silliness of it, since
LET x = expr IN { e1; e2; }
LET x = expr IN ( e1; e2; )
are completely equivalent. The problem with *not* having some form of
bracketing is that
LET x = expr IN e1; e2;
e3
is really
LET x = expr IN e1; e2; e3
And before somebody asks (because I know somebody will), no, I am not
going to use indentation-based scoping -- at least, not in this pass.
Another way to look at this, I suppose, is that the behavior when ";"
is seen in the absence of brackets is "reduce", not "shift".
shap
More information about the bitc-dev
mailing list