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