[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