Lucas Kramer

One slight wrinkle is that there are some cases where we want the implementation productions to have different signatures. For example: ``` concrete production attributeDef top::ProductionStmt ::= dl::DefLHS '.' attr::QNameAttrOccur...

Another issue - sometimes dispatch productions have additional children, and are partially applied where the overload is defined. For example ``` dispatch Reference = Expr ::= @q::QName; synthesized attribute refDispatcher...

Above I stated > Note that `undecorates to` is no longer needed in implementation productions, as these productions can only be constructed as the root of the forward tree. Thus...

> To enforce this, I think we want to forbid taking a reference to the LHS of production with shared children. This raises an issue with default productions. Consider something...

I was just discussing with @ericvanwyk the issue of how dispatch productions like `negOp` (and any productions forwarding to it with sharing) cannot make use of an extension inherited attribute...

> To enforce this, I think we want to forbid taking a reference to the LHS of production with shared children. Actually, there's a much simpler solution to preventing dispatch...

Yeah, the trouble is that ``` let local resType::Type = ...; ``` vs. ``` local resType::Type = ...; ``` doesn't really say anything about being decorated or not, which might...

I guess dividing things in this way that also simplifies a presentation of the type rules - `local`/`production` always just bind the declared type, vs. `local decorate`/`production decorate` always wrap...

Having `term` as a keyword wouldn't be an issue. But I think for consistency the decorating version should only be used for nonterminals, and the non-decorating version would also be...

Okay, the consensus was ``` local term resType::Type = ...; ``` and ``` production term resType::Type = ...; ``` for the non-decorating versions. This new syntax will only permit nonterminals....