[Grammatica-devel] Re: Specialized node types update

[Per Cederberg]

Great work, Connor!

Could you send me you Google Account email (or create one) so that I
can give you commit access to Google Code?

  http://code.google.com/p/grammatica

It's much easier for everyone if you can apply your changes directly,
in the logical order.

Thanks again!

/Per

On Tue, Jul 14, 2009 at 15:10, Connor Robert Prussin<address@hidden> wrote:
> Per (and other users)-
>
> I am a student who is using the Grammatica project.  I have written up
> modifications to implement "specialized" node types (see
> http://code.google.com/p/grammatica/wiki/FeatureProductionSubclasses).  The
> attached patch successfully implements these nodes in Java, and I'm working
> on the C# version.
>
> You will notice that the patch adds a "--specialize" CLI switch.  Without
> this switch, Grammatica performs the exact same as before this patch.  With
> the switch, however, it prints out a directory full of classes that extend
> "SpecializedProduction" (which in turn extends "Production").  Note also
> that the new classes won't actually be used unless a user does something
> along the lines of:
>
>         Node head = new GeneratedParser(new FileReader(fileToBeParsed), new
> GeneratedAnalyzer() {}).parse();
>
> or
>
>         Node head = new GeneratedAnalyzer() {}.analyze(new
> GeneratedParser(new FileReader(fileToBeParsed)).parse());
>
> Basically this means that even if the "--specialize" switch is set,
> backwards compatibility can still be achieved after class generation by
> simply using something like:
>
>         Node head = new GeneratedParser(new
> FileReader(fileToBeParsed)).parse();
>
> However, actually using the "--specialize" flag then attempting backward
> compatibility is untested.  It just must be noted that the correct analyzer
> HAS to be used to get the specialized nodes.
>
> Also, you will notice that the "synthetic" productions are not "spliced" out
> of the parse tree when using "--specialize."  This is due to logistical
> issues with the well-named accessors.  While programming, we found no good
> way to efficiently get all the possible accessors of a production and still
> get rid of the synthetic productions.  We kept them with the mindset that
> the majority of people using the "--specialize" flag will be writing
> grammars in a style that will not have a lot of synthetics.  For an example
> of a production rule that would be troublesome in generating classes and
> accessors, consider:
>
>         production1 = production2 (produciton3 | production4) ;
>
> In this case, do we write accessors for Production3, Production4, or both?
> The simple answer is, there is no way at code generation time.  Thus, the
> nodes printed are simply production1, production2, and an interface
> "production1_S1" that is implemented by either production3 or production4.
>
> Also note that the generated classes have prefixes of either "i_," "a_," or
> "t_."  The "t_" classes are tokens--the classes are simply written to enable
> use of language features like "instanceof."  the "i_" classes are
> interfaces--node types which have no children themselves.  In the last
> example "production1_S1" would get an "i_" prefix, as would production5 in
> the following example:
>
>         production5 = production6 | production7 | production8 ;
>
> Finally, the "a_" classes are "alternatives"--node classes that correspond
> to rules that have children.  These have well-named generated accessors that
> are much easier to use than simply the children[] object.
>
> Again, I'm currently working on the C# implementation.  As it is basically a
> copy-paste port of what has already been written for Java, it should not
> take much time.  I hope the new modifications are useful!
>
> Sincerely,
>
>
> Connor Prussin
>