[bitc-dev] Bracketing conventions

[Jonathan S. Shapiro]

On Thu, Apr 1, 2010 at 1:14 PM, Elias Gabriel Amaral da Silva
<tolkiendili at gmail.com> wrote:
> 2010/4/1 Jonathan S. Shapiro <shap at eros-os.org>:
> (..)
>>  LET x = expr IN expr;
>>  LET x = expr IN { e1; e2; }
>
> The problem I see here is that nested lets aren't supposed to require
> nesting in syntax level...

In BitC, a single LET form can bind multiple identifiers, so we *do*
intend that each let introduces a new indentation level. BitC let is
"let multiple", as in LISP.

> As a side note, I would rather not have this "in" there.

The "in" (or something comparable) is necessary to signal the end of
the let bindings and the beginning of the scope in which the bindings
are defined.

>> The reason to prefer strong bracketing (whether through braces or
>> keywords) is disambiguating the parse, and particularly the
>> interactive parse.
>
> I like implicit syntax. I would rather almost never say explicitly an
> begin/end or { }, than say it most of time

The implicit syntax leads to a (horribly) ambiguous parse, which makes
it very difficult to do useful IDEs for the language. We are going to
have brackets on this construct. The only question is what kind.

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

I've already stated that white space will not be significant in BitC.

> But I can not see a reason for creating a
> binding that will last only for some statements in a chain...

There are lots of reasons to have local bindings. The question at hand
is how to determine syntactically where the inner scope ends.

> ...maybe to
> ease support for machine-generated code? (But machine-generated code
> would use the s-expr syntax..)

The s-expression syntax will be completely gone by language version 0.12.


Jonathan