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? > > 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. > You could go the C-style way: preprocessing tokens vs. tokens. Your preprocessing tokens would be "=", "block of text lines with same indentation", and layout directive. Then you further convert the preprocessing tokens into tokens by lexing the "block of text lines with same indentation" into sequence of tokens. > > 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
