[bitc-dev] Bracketing conventions

[Elias Gabriel Amaral da Silva]

Hello! This is my first message here (I was previously only watching).

I'm not actually familiar with bitC language, but it is interesting to me.

2010/4/1 Jonathan S. Shapiro <shap at eros-os.org>:
(..)
>  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 problem I see here is that nested lets aren't supposed to require
nesting in syntax level (at least ml-style lets - lisp-style seems to
be different). So I have, in OCaml (I am almost certain this work in
SML too):
let a = 1 in
let b = 2 in
a + b

instead of

let a = 1 in
  let b = 2 in
    a + b

This is because if your code have a lot of let .. in, it is usually
easier to understand without nesting

See that we have, here, an implicit end. This complicates things in
top-level, requiring ;; at the end of the input. Yes, this is ugly.

In ocaml, the implicit end always works with functional code, as long
as the top-level constructs aren't expressions (in ocaml, the
workaround is to have let _ expr1 let _ = expr2 .. etc, or let () =
expr, if one wants to have expressions in top-level). If we want to
put expressions on top-level, we need an ugly ;; after them. But with
imperative code, it will sometimes fail in borderline cases, such as
nested ifs and a if inside a match. (Hmm, I think the code does not
need to be imperative for failing with nested ifs..)

But this will actually work:

let a = 1 in
let b = 2 in
Printf.printf "%d\n" (a+b);
a + b

As seen by this top-level interaction

# let a = 1 in let b = 2 in Printf.printf "%d\n" (a+b); a+b;;
3
- : int = 3

this is the same as
let a = 1 in
let b = 2 in begin
  Printf.printf "%d\n" (a+b);
  a+b
end

and could in fact be translated to brace style (but not in ocaml)

let a = 1 in
let b = 2 in {
  Printf.printf "%d\n" (a+b);
  a+b
}

ruby, in fact, support /both/ styles. braces usually are used for
one-liners, and do .. end for multi-line. so, if you are ok in letting
programmers choose their own syntactic convention, you can give this
as an option, too.

As seen in http://onestepback.org/index.cgi/Tech/Ruby/BraceVsDoEnd.rdoc
, not every ruby programmer agree with the mainstream convention, and
this could be a problem for bitC. (This kind of thing seems to be a
minor problem for C, with its multiple curly braces style. This was
nicely solved in Go - did you saw Go grammar?)

As a side note, I would rather not have this "in" there. Did you see
the oz dataflow variables? They are like one-time lets, and the syntax
is just a simple variable assignment, and not the mathematician's "let
y = x+1 in .., so .."

> 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.

I like implicit syntax. I would rather almost never say explicitly an
begin/end or { }, than say it most of time

(For the same reasons, I like languages that put the ; in the end of
line for me. I would gladly put a \ on the end of line if I want to
continue the code on the next line in order to have this - and, since
I almost never do this, it's a win-win)

(..)
> 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

Unless the line break has some significance. But, yes, optional
braces/begin-end seems to be a win, if the default is sensible enough
so that the braces are used just in some minor exceptions (and it is
certainly useful in OCaml). But I can not see a reason for creating a
binding that will last only for some statements in a chain; maybe to
ease support for machine-generated code? (But machine-generated code
would use the s-expr syntax..)

-- 
Elias Gabriel Amaral da Silva <tolkiendili at gmail.com>