Thanks Shinji, The conversions are indeed though :) The problem is with the indirect/mutual recursions. Even if you deal with recursions, Anltr manages to find ambiguities, but they can be dealt with backtracking or syntactic/semantic predicates of Antlr. Maybe I should fire up a Ruby environment and see your solutions :)
Regards Seref Ps: For those who have lost precious brain cells to parsers at one point in their lives, I'm still resisting the idea of going back to "the dragon book"... On Thu, Jan 5, 2012 at 10:05 AM, Shinji KOBAYASHI <skoba at moss.gr.jp> wrote: > Hi Seref, > > Left recursive rule is theoretically rewrite to equivalent right recursive. > In ADL grammar, cADL has left recursive rule that cannot be parsed by LL, > so I converted them to right recursive rules. > For example of left recursive to explain(shorten for convenience) > > arithmetic_expression: > arithmetic_leaf > | arithmetic_node > > arithmetic_node: > arithmetic_expression '+' arithmetic_leaf > |... > > arithmetic_leaf: > (an arithmetic element) > > I converted this grammar to this right recursive rule. > > arithmetic_expression: > arithmetic_leaf > | arithmetic_node > > arithmetic_node: > arithmetic_leaf '+' arithmetic_expression > |... > > These conversions were the most tough points. > I wish I could help you. > > Regards, > Shinji > > 2012/1/5 Seref Arikan <serefarikan at kurumsalteknoloji.com>: > > Thanks Shinji, > > In general, Antlr has some convenient features, infinite lookahead being > one > > of them. I've quickly checked, and Treetop does not seem to support left > > recursion either. So you must have modified the grammar to make it work. > > I'm referring to grammar rules such as > > A : A | B; > > > > Tom made the point earlier. At one point it would be good to unify > various > > AQL implementation experiences. I'll check out the papers. > > > > Best regards > > Seref > > > > > > > > On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI <skoba at moss.gr.jp> > wrote: > >> > >> Hi Seref, > >> > >> My ADL parser does not include AQL parsing. > >> I used Treetop, which is an Ruby implementation of PEG/Packrat parsing > >> algorithm, > >> not LL/LR. PEG/Packrat parser algorithm was described in this paper. > >> http://bford.info/pub/lang/packrat-icfp02/ > >> > >> Antlr is an implementation of PEG parser by LL techniques. I do not > >> know Antlr so much. > >> > >> Packrat parser does not need to separate scanner/parser/lexer and is > >> capable to > >> infinite look ahead recursive. > >> > >> I do not know why are you parsing AQL, but this proceeding about > querying > >> EHR > >> by archetype might be helpful for your research. > >> http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf > >> > >> Best regards, > >> Shinji > >> > >> 2012/1/5 Seref Arikan <serefarikan at kurumsalteknoloji.com>: > >> > Greetings, > >> > The AQL grammar from the wiki has direct and indirect left recursion. > >> > Which > >> > means without changes in the grammar, LL parser generators (both > JavaCC > >> > and > >> > Anltr) can't generate parsers for this grammar. > >> > > >> > I'm curious if anybody has refactored this grammar for LL parser > >> > generators. > >> > Shinji? Your latest release includes an AQL parser does not it? Could > >> > you > >> > please share your method? I can always look at the code, but you'd > >> > probably > >> > save me time :) > >> > > >> > I'm interested in experiences of others too. > >> > > >> > > >> > Kind regards > >> > Seref > >> > > >> > > >> > _______________________________________________ > >> > openEHR-technical mailing list > >> > openEHR-technical at openehr.org > >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >> > > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at openehr.org > >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/17f73d6d/attachment.html>
