Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] Jikespg syntax description used in ...compiler.batch/grammar/java.g

Dear Stefan,

that documentation is a great start. I just quickly read it, not
claiming to have understood everything. But next time I need to work on
the AspectJ grammar, this will be a good guide to understand more about
the grammar and the parser generator. I think, if we get more insights
into the two types of equality symbols I am also talking about with
Manoj, maybe it shall be possible to improve this description on the
wiki page:

>> Two different symbols are used to map a non-terminal to a grammar
>> expression: ::= and ->. Only rules using the former symbol carry
>> actions to be performed by the parser (it is not clear if this is
>> enforced or by convention only)

Either way, the distinction you described it a good guideline about how
to use them, enforced or by convention. My feeling still is that the two
symbols might be used interchangeably, but feelings are not facts.

Looking at https://github.com/A-LPG/LPG2-grammars-example/tree/main, the
example grammars (*.g files in subdirectories) there, except for the JDT
example, actually use '::=' exclusively in their rules. Only we also use
'->' for our rules, which makes me think that maybe the author only
keeps the arrow notation around for Jikespg backward compatibility.

Another interesting detail, referring to your wiki comment here...

>> For lack of operators like |, alternatives are written by a set of
>> rules with the same LHS non-terminal

... is that A-LPG2 actually does seem to support '|', see e.g.
https://github.com/A-LPG/LPG2-grammars-example/blob/97cea00djava/GJavaParser.g#L303-L306.
Example quote:

    ImportDeclaration ::= SingleTypeImportDeclaration
                        | TypeImportOnDemandDeclaration
                        | SingleStaticImportDeclaration
                        | StaticImportOnDemandDeclaration

I.e., if JDT Core ever feels like migrating from Jikespg to A-LPG2,
chances are that the grammar file could be streamlined and be made more
readable. That is, of course, just syntactic sugar, but I would not
dismiss it so quickly.

--
Alexander Kriegisch
https://scrum-master.de


Stephan Herrmann schrieb am 05.01.2023 um 18:05:
> I made a stab at documenting what I know about (the syntax of) java.g:
>     https://wiki.eclipse.org/JDT_Core_Programmer_Guide/ECJ/Parse#The_Grammar
> 
> You will notice that a few details are written in a vague wording, simply 
> because I'm not really sure.
> 
> It would be great if a couple of experts review (and improve?) this. Also 
> feedback from Alexander would be appreciated :)
> 
> I'm slightly worried about still investing in the wiki after its best-before 
> date. What is JDT's take at migrating "all that is relevant" into a "more 
> modern" wiki?
> 
> best,
> Stephan
> 
> Am 05.01.23 um 10:46 schrieb Jayaprakash Arthanareeswaran:
>> This is something we rarely do. So, nobody bothered to do this.
>> And as long as this being static, it doesn't help anyway.
>>
>> About your question, I vaguely remember there being a difference
>> ::= and ->. I and Manoj discussed this but I don't recall what the difference was.
>>
>> Regards,
>> Jay
>>
>> -----Original Message-----
>> From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Alexander Kriegisch
>> Sent: 05 January 2023 13:40
>> To: jdt-dev@xxxxxxxxxxx
>> Subject: [EXTERNAL] Re: [jdt-dev] Jikespg syntax description used in ...compiler.batch/grammar/java.g
>>
>> I also forgot to ask what the rationale behind making the DEBUG field final is? The compiler optimising the 'if (DEBUG)' statements? While trying to solve my issue, it would have bveen nice to be able to set the flag dynamically instead of having to recompile JDT Core.
>>
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>> Alexander Kriegisch schrieb am 05.01.2023 um 09:03:
>>
>>> BTW, the way I was able to debug this was to set Parser.DEBUG to true
>>> and compile a JDT Core version with it, running my regression test
>>> against it, watching what was actually being parsed. Is there a more
>>> elegant way to debug grammar problems? And is there an IntelliJ or
>>> Eclipse plugin helping me to highlight the syntax of and navigate or
>>> even code-complete stuff in files like java.g? Especially the
>>> navigation part was difficult, repeatedly jumping around by searching
>>> for production names. Please also note that the AspectJ grammar is
>>> more complex than the plain Java grammar, the latter being just a
>>> subset of the former.
>> _______________________________________________
>> jdt-dev mailing list
>> jdt-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
>> _______________________________________________
>> jdt-dev mailing list
>> jdt-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
> 
> _______________________________________________
> jdt-dev mailing list
> jdt-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
> 


Back to the top