[antlr-interest] Duplicate members when generating code with 2 import levels in Java with ANTLR-3.1.1

[Loring Craymer]

----- Original Message ----
> From: Terence Parr <parrt at cs.usfca.edu>
> To: Loring Craymer <lgcraymer at yahoo.com>
> Cc: antlr-interest Interest <antlr-interest at antlr.org>
> Sent: Tuesday, October 28, 2008 10:25:21 AM
> Subject: Re: [antlr-interest] Duplicate members when generating code with 2 import levels in Java with ANTLR-3.1.1
> 
> 
> On Oct 28, 2008, at 1:35 AM, Loring Craymer wrote:
> 
> > Ter--
> >
> > Indirect execution is a very weak form of polymorphism, and the  
> > mechanism you describe depends on compiler type awareness.
> >
> > Assume that you have two versions of rule b, defined in separate but  
> > included grammars
> >
> > b[int foo] : a b c ;  // version 1
> >
> > b returns int :  d e f ; // version 2
> >
> > These have different type signatures; in an OO system, b[int x]  
> > would translate to version 1, and z = b would imply version 2.
> 
>   isn't that overloading rather than overwriting? nothing to do with  
> object-oriented programming if I remember correctly.

Overwriting?  What does that have to do with polymorphism?  Maybe you are thinking of Java's type erasure in generics.  Overloading is a mechanism for implementing polymorphism.

> 
> > As you mention, interpretation depends on the message sent, and part  
> > of the message are the data type expectations.
> 
> but unless you are using ML and so on,  most languages are not  
> polymorphic on the argument types or the return signatures.

Actually, modern languages are, although the polymorphism is static.  Consider the usual Java examples
toString()
toString(int indent)
...

Java supports argument polymorphism, but not return type polymorphism; I believe that the same is true for C++ and C#, but am not sure of that--C++ name mangling is capable of supporting return type polymorphism.

> 
> > On another note, ANTLR lacks the data abstractions that go with the  
> > OO idea of inheritance.  The mechanism implemented in ANTLR 3 looks  
> > much more like Python's module import facility than it does  
> > inheritance.
> 
> Can you give an example of what you can't do with antlr's grammar  
> composition that you could do with an ordinary object oriented  
> language?  *the* quintessential example of polymorphism is the one I  
> gave where you inherit method that calls a method overridden in the  
> subclass. If your language doesn't do that, it's not polymorphic. what  
> you're talking about is something totally different: parameter-based  
> polymorphism or simple overloading as you describe above.

Unless I am very much mistaken, composed grammars do not incorporate action code from subgrammars, other than that embedded in productions.  That is, data and behavioral semantics from subgrammars are not inherited and thus the OO paradigm is violated.  Productions are also not polymorphic, as discussed above.

I repeat:  as implemented, grammar composition is almost identical to Python's module imports and does not fit the OO inheritance model except by a long stretch of the imagination.

--Loring


> Ter