[antlr-interest] Composite grammar support in antlr4.0ea

Terence Parr parrt at cs.usfca.edu
Tue Jan 3 16:31:39 PST 2012 

You should have imports in the header and fields and constructors etc. in the members area, but only put those actions in the root grammar not in the subordinates.

Ter
On Jan 2, 2012, at 7:23 PM, Dave Thomas wrote:

> This may be my AHA moment.
> 
> When I put imports in members my parsers get:
> 
> class Java_JavaDecl extends Parser {
> 
> //delegates
> 
> //delegators
> 
> //constructors
> 
> *import com.test.Type;*
> 
> //everything
> 
> }
> 
> What java needs to compile is to put the import outside the class block:
> 
> *import com.test.Type;*
> 
> class Java_JavaDecl extends Parser {
> 
> //delegates
> 
> //delegators
> 
> //constructors
> 
> //everything
> 
> }
> Is there a way to change this behavior?
> 
> 
> On Mon, Jan 2, 2012 at 9:26 PM, Terence Parr <parrt at cs.usfca.edu> wrote:
> 
>> Hi Dave,What do you want to put in the header? imports? Perhaps you are
>> putting stuff in the header that should be in the members action?
>> Ter
>> On Jan 2, 2012, at 1:51 PM, Dave Thomas wrote:
>> 
>>> Thanks, Ter!
>>> 
>>> It sounds like the subordinate grammar means the dependent grammar which
>> in
>>> my case is the root combined grammar Java.g (per
>>> http://www.antlr.org/wiki/display/ANTLR3/Composite+Grammars).
>>> 
>>> It totally makes sense that an incomplete grammar cannot stand alone in
>> its
>>> own package.  I had originally envisioned different packages for major
>>> components of my language but it's not a real necessity and their
>> coupling
>>> could complicate things.
>>> 
>>> I also agree grammars shouldn't be forced into the package of their
>>> dependencies.
>>> 
>>> However it seems that I get a duplicate header definition error on all
>>> parser grammars (including combined grammars) regardless of whether they
>>> contain the same package.  I can't see how this is intended to work when
>>> the header contains imports, which seems to me to be a fairly common
>> case.
>>> An updated tarball with a concrete example is attached.  I put all
>>> grammars in the same package for simplicity.
>>> 
>>> The simplest thing that could work would be to have a subordinate grammar
>>> override the header of it's dependency (as illustrated in the attached
>>> example).  This can work but I suspect requires the subordinate duplicate
>>> the code of it's dependencies.  In fact I just discovered (at least with
>>> v4) that although antlr spits our the error and nonzero return code, it
>>> appears to be properly emitting this!
>>> 
>>> In an ideal world (ahem crazy, badass like the honey badger) we might
>> come
>>> up with a way of scoping to either share common headers (like
>>> includes/imports) or allow disjoint ones (like specifying the package).
>>> 
>>> ... or am I truly missing the obvious and trying to do it "the hard way"
>> ?
>>> 
>>> Thanks and Happy New Year!
>>> On Jan 2, 2012 12:36 PM, "Terence Parr" <parrt at cs.usfca.edu> wrote:
>>> 
>>>> Hi Dave,Because the subordinate important grammars are not complete,
>> they
>>>> should not have a header that specifies the package. Very least, it's
>> more
>>>> flexible to not force subordinate grammars into certain packages. Is
>>>> correct that you have duplicate header definition because you specify
>> the
>>>> package twice.
>>>> 
>>>> v4 didn't complain about this so I will have to add an error.
>>>> Thanks,
>>>> Ter
>>>> On Jan 1, 2012, at 8:21 PM, Dave Thomas wrote:
>>>> 
>>>>> With all this exciting Honey Badger activity (which is just crazy and
>>>>> doesn't give a shit), I thought I'd bump this "Redefinition of header
>>>>> action" thread and attach a minimal tarball with code for your
>>>> convenience!
>>>>> 
>>>>> I get the same result with antlr-4.0ea (as I did with 3.4 nicely
>>>> mavenized)
>>>>> by running:
>>>>> cd src/main/antlr3; java  -cp
>>>>> /path/to/antlr-4.0ea-complete.jar:/path/to/ST-4.0.4.jar org.antlr.Tool
>>>>> test/*.g -o ../../../target
>>>>> error(144): JavaDecl.g:3:2: redefinition of header action
>>>>> 
>>>>> 
>>>>> On Tue, Nov 22, 2011 at 9:07 PM, Dave Thomas <
>> opensource at peoplemerge.com
>>>>> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I'm using ANTLR for my masters thesis, which includes letting user
>>>> extend
>>>>>> the lex and parser grammars I supply with their own jargon in the form
>>>> of a
>>>>>> combined grammar.  I wouldn't have dreamed it possible before ANTLR,
>> and
>>>>>> I'm a big fan!
>>>>>> 
>>>>>> The problem I'm having is:
>>>>>> error(144): JavaDecl.g:3:2: redefinition of header action
>>>>>> 
>>>>>> The reason this is making me scratch my head is that I see this issue
>>>> has
>>>>>> been reported, and AFAICT addressed:
>>>>>> http://www.antlr.org/jira/browse/ANTLR-301
>>>>>> http://www.antlr.org/jira/browse/ANTLR-370
>>>>>> http://www.antlr.org/jira/browse/ANTLR-375
>>>>>> 
>> http://www.antlr.org/pipermail/antlr-interest/2011-January/040487.html
>>>>>> http://www.antlr.org/wiki/display/ANTLR3/Composite+Grammars (basis
>> for
>>>>>> the examples; sorry for the cross-post)
>>>>>> 
>>>>>> Am I specifying the antlr release wrong in the maven plugin?
>>>>>> 
>>>>>> Should I be concerned that my dependency hierarchy includes antlr
>> 2.7.7?
>>>>>> Per
>> http://www.antlr.org/wiki/display/ANTLR3/ANTLR+3.4+Release+Notesthe
>>>>>> dependency on v2 should be removed, but I still see it when I do `mvn
>>>> clean
>>>>>> antlr3:antlr compile -X`:
>>>>>> 
>>>>>> [DEBUG]    org.antlr:antlr:jar:3.4:compile
>>>>>> [DEBUG]       org.antlr:antlr-runtime:jar:3.4:compile
>>>>>> [DEBUG]          org.antlr:stringtemplate:jar:3.2.1:compile
>>>>>> [DEBUG]          antlr:antlr:jar:2.7.7:compile
>>>>>> 
>>>>>> 
>>>>>> src/main/antlr3/test/JLex.g
>>>>>> 
>>>>>> lexer grammar JLex;
>>>>>> @lexer::header { package test; }
>>>>>> 
>>>>>> INT : 'int';
>>>>>> SEMICOLON : ';';
>>>>>> EQUALS : '=';
>>>>>> ID : ('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'0'..'9'|'_')*;
>>>>>> 
>>>>>> 
>>>>>> src/main/antlr3/test/JavaDecl.g
>>>>>> 
>>>>>> parser grammar JavaDecl;
>>>>>> @header { package test; }
>>>>>> type : INT ;
>>>>>> decl : type ID SEMICOLON
>>>>>>   | type ID init SEMICOLON
>>>>>>   ;
>>>>>> init : EQUALS INT ;
>>>>>> 
>>>>>> 
>>>>>> src/main/antlr3/test/Java.g:
>>>>>> 
>>>>>> grammar Java;
>>>>>> import JavaDecl, JLex;
>>>>>> @header { package test; }
>>>>>> prog : decl ;
>>>>>> type : 'int' | 'float' ;
>>>>>> 
>>>>>> pom.xml:
>>>>>> 
>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>>>>>> http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>>>> http://maven.apache.org/xsd/maven-4.0.0.xsd">
>>>>>> <modelVersion>4.0.0</modelVersion>
>>>>>> <groupId>test</groupId>
>>>>>> <artifactId>test</artifactId>
>>>>>> <packaging>jar</packaging>
>>>>>> <version>1.0-SNAPSHOT</version>
>>>>>> <name>test</name>
>>>>>> <build>
>>>>>> <plugins>
>>>>>> <plugin>
>>>>>> <groupId>org.antlr</groupId>
>>>>>> <artifactId>antlr3-maven-plugin</artifactId>
>>>>>> <version>3.4</version>
>>>>>> <executions>
>>>>>> <execution>
>>>>>> <configuration>
>>>>>> <goals>
>>>>>> <goal>antlr</goal>
>>>>>> </goals>
>>>>>> </configuration>
>>>>>> </execution>
>>>>>> </executions>
>>>>>> </plugin>
>>>>>> </plugins>
>>>>>> </build>
>>>>>> </project>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> <antlr-header.tar>
>>>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>>>>> Unsubscribe:
>>>> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>>>> 
>>>> 
>>> <antlr-header.tar>
>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>>> Unsubscribe:
>> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>> 
>> 
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address

More information about the antlr-interest mailing list