I'm not going to be able to address this issue until the second week of June.
That said, it seems the best way to handle all these issues with delegate grammars is to inline their rules before code generation. Suppose you have grammar C importing A and B, and you also have D importing A and B. The code generation will result in classes C, C_A, C_B, D, D_A, and D_B. Clearly the independent generation of C_A and D_A during code generation does not allow a single instance of the imported A grammar to be shared by C and D. If we instead "flatten" the imported grammar hierarchy and only generate classes C and D, then everything behaves like it was written in a single grammar. Do you see any immediate problems with this potential approach? -----Original Message----- From: Ranco Marcus [mailto:ranco.mar...@epirion.nl] Sent: Wednesday, May 25, 2011 4:26 PM To: Sam Harwell; antlr-interest@antlr.org Subject: RE: [antlr-interest] [CSharp3] rule visibility in composite grammars Hi Sam/all, When a (tree) grammar C imports (tree) grammars A and B, where grammar A calls a rule R from grammar B, a call is being made from delegate parser C_A to a delegate rule R (targeting C_B) in the composite parser C (its parent). Now that the visibility of the delegate rules in C match the visibility of the imported grammar, the rule R has to be made public for the above to work. In our grammars, we build up internal structures that are subsequently processed. In our case, that means that all those internal structures have to be made public as well. This could be solved by allowing ANTLR rules to have 'internal' visibility. Also, imported grammars can probably remain internal as well. What are your thoughts on this? Thanks, Ranco > -----Original Message----- > From: Sam Harwell [mailto:sharw...@pixelminegames.com] > Sent: Thursday, April 07, 2011 3:57 PM > To: Ranco Marcus; antlr-interest@antlr.org > Subject: RE: [antlr-interest] [CSharp3] rule visibility in composite > grammars > > The visibility of delegated rules now matches the way they're declared > in the imported grammar. Since some of them return nested classes > declared in the delegate grammar, I had to make the delegate grammar > 'public' and all its rules 'internal'. > > I fixed the reserved names issue right after releasing 3.3.1, so it'll > be included when I release 3.3.2. Note that rule parameters and return > values need to include an explicit '@' in their declarations in the > grammar, as follows. Labels and rule names do not need the '@'. > > namespace[int @in] returns [int @out] : as=A B; > > Sam > > -----Original Message----- > From: Ranco Marcus [mailto:ranco.mar...@epirion.nl] > Sent: Thursday, April 07, 2011 6:49 AM > To: Sam Harwell; antlr-interest@antlr.org > Subject: RE: [antlr-interest] [CSharp3] rule visibility in composite > grammars > > Sounds great, Sam! > > What will be the visibility of the methods in the 'Delegated rules' > region now that the class of the imported grammar is internal? Private or internal? > > Another small suggestion is to prefix variable names (at least those > that are reserved in C#) with an at-sign. The generated class for the > grammar below has a compile error since 'as' is not a valid variable name while '@as' is. > > name : as=firstName lastName; > > Are you planning to release new binaries any time soon? > > Thanks again, > > Ranco Marcus > > > -----Original Message----- > > From: Sam Harwell [mailto:sharw...@pixelminegames.com] > > Sent: woensdag 6 april 2011 17:20 > > To: Ranco Marcus; antlr-interest@antlr.org > > Subject: RE: [antlr-interest] [CSharp3] rule visibility in composite > > grammars > > > > Hi Ranco, > > > > I made the following changes so far: > > > > * An imported grammar is always generated as an internal class > > instead of a public class. > > * Rules within the imported grammar are always declared public since > > they are only called by the root grammar. > > > > How does that sound? > > > > Sam > > > > -----Original Message----- > > From: antlr-interest-boun...@antlr.org > > [mailto:antlr-interest-boun...@antlr.org] On Behalf Of Ranco Marcus > > Sent: Wednesday, March 23, 2011 6:40 AM > > To: antlr-interest@antlr.org > > Subject: [antlr-interest] [CSharp3] rule visibility in composite > > grammars > > > > Hi all/Sam, > > > > While using the CSharp3 target on a composite grammar, I came across > > a few issues regarding rule visibility. > > > > If no modifier (private, protected, public, ...) is specified for a > > rule, the Java target generates public methods (since it is not > > implemented IIRC) and the > > CSharp3 target generates private methods. > > > > I like the idea to explicitly specify which rules are callable (by > > making them public). However, for composite grammars the generated > > parser contains delegate rules for every rule of the imported > > grammar, even for rules in the imported grammar that aren't public > > (causing compile errors). This can solved this adding a public > > modifier to every rule of the imported grammar, but I was wondering > > if there's a more > convenient way of doing this. > > > > Furthermore, the methods for the delegate rules in the composite > > grammars are all public, regardless of the visibility of the rule in > > the > imported grammar. > > IMHO, it would be better to make them private and use the composite > > grammar to explicitly specify the rules that are externally visible. > > What are your thoughts on this? > > > > Btw, the CSharp3 templates are also included in the original Java > > tool. Does that mean that we don't need the .NET version of the tool > anymore? > > > > > > Best regards, > > > > Ranco Marcus > > Epirion Knowledge Solutions B.V. > > > > > > List: http://www.antlr.org/mailman/listinfo/antlr-interest > > Unsubscribe: > > http://www.antlr.org/mailman/options/antlr-interest/your-email-addre > > ss > List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
