On Fri, Sep 5, 2014 at 4:04 PM, Jonathan S. Shapiro <[email protected]> wrote:
> Well, I've read the paper, and I have two questions about it. The first
> isn't really important, except that I'm curious if the approach can handle
> it.
>
> 1. In assignments/bindings, it's sometimes nice to require that the
> initializing expression must remain entirely to the right of the '=' token
> if it spreads across multiple lines. In the Adams work, there doesn't appear
> to be a way to establish an indentation relation between two items that are
> on the RHS of the same production. Can anybody see a way to write a grammar
> rule using this system that has the effect I want?
Isn't this sufficient?
let = "let" var |rhs|
rhs = '=' ...^(>)
Geoffrey
> Strictly speaking we'd need a way to say "the start of this token must be
> after the end of that one", so for the sake of this question lets just say
> that the expression must be more indented than the beginning of the '='
> sign.
>
> 2. I'm troubled by the move in 5.6 to restrict the grammar to LR(k) grammars
> in order to remove ambiguity. My recollection of BitC v0 was that I had to
> fiddle with the token stream and actually push tokens onto it, and there
> were a couple of cases that introduced ambiguities that could only be
> resolved by exploiting (i.e. abusing) the error handling mechanisms. I think
> there was a case where the grammar really wasn't LR(k) unless an opening
> curly brace was injected. That is: unless layout is considered. I read 5.6
> to be requiring that the grammar be LR(k) after erasing all indentation
> constraints.
>
> Overall this looks like a nice piece of work. Though Adams doesn't mention
> it explicitly, it happens to solve the bracket insertion "agreement"
> requirement as well. That is: either both the opening and closing brace are
> inserted by layout or neither is inserted by layout. Among other reasons,
> that's useful because paren matching in editors gets completely boogered if
> you don't require it.
>
> I sorta wish he'd given the constructions for LR and LL tables under this
> approach, but I can re-derive them.
>
>
> shap
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
