Re: PPCompositeParser>>initializeStartingAt:

> However, while figuring this out, I noticed this following bit:
>
> ...
>
>        parser := PPUnresolvedParser named: aSymbol.
>        productionIndexesAndNames do: [ :assoc |
>                self instVarAt: assoc key put: (PPUnresolvedParser named:
> assoc value) ].
>        parser := self perform: aSymbol.
> ...
>
> It seems that the last line of the snippet should read:
>        parser def: (self perform: aSymbol).

>
> This would be consistent with how the rest of the productions initialize
> themselves and wouldn't make the first line of the snippet pointless.
>
> I can't really discern any difference in commenting out line one, leaving
> everything as is, or shifting the last bit to def: So I'm missing something!
>
> Cheers,
> Bijan.
>

> On 8/3/10 10:22 AM, Lukas Renggli wrote:
>
> Hi Bijan,
>
> Please ask further questions in the Moose mailing-list, other people
> might be interested too.
>
>
>
> Thanks for sharing it:
> I would be definitively happy to read
> any discussion related to PetitParser! :)
>
> Btw, it seems that the Java grammar (i.e. PetitJava) is coming.
>
> Just to share my experience, I first tried to implement it
> following the Java Language Specification book, Chapter 18.
> Even though such chapter should sum up the whole syntax, it is not
> completely consistent with the rest of the book (which details
> all the rules with explanations and examples), and presents some
> errors. Thus, after a brief trial, I moved to implement
> the grammar according to the more detailed version.
> Alas, such chapters are not perfect, too!
> I found out a "corrected" version in a web site [1].
> When finally I managed to implement it, it turned out that such
> specifications contain various cycles. I tried to fix them, but
> that would have required much time.
> So, I decided to take the ANTLR version of the java grammar
> (which has been tested successfully over a comprehensive regression
> test suite) that would contain no dangerous cycles (since it is LL(1))
> for PetitParser [2].
> Now that grammar is implemented, and it correctly parses the
> compilation units I tried. It still needs work (first of all, more
> tests. Then, a parser), but it's coming.
>
> From this experience, I would say that the first translator from
> grammar-in-another-specification to PetitParser, should be from
> ANTLR grammars. The fact that they are LL(1) should avoid cycles
> (please correct me, if I am wrong), and there is a very big number
> of grammars written for ANTLR.
>
> Ciao,
>  Alberto
>
>
> [1] http://www.cmis.brighton.ac.uk/staff/rnb/bosware/javaSyntax/Java1_6GrammarCorrected.html
> [2] http://openjdk.java.net/projects/compiler-grammar/antlrworks/Java.g
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

> On 8/3/10 2:14 PM, Lukas Renggli wrote:
>> Hi Alberto,
>>
>> This is great news. Maybe you also want to post the repository URL? :-)
>
> Sure, please don't be too much horrified by the quality of the code:
>
> http://www.squeaksource.com/PetitJava.html
>
>> For what you noticed on bogus grammar specifications check out the
>> work of Vadim Zaytsev (http://mobile.twitter.com/grammarware). Among
>> others he analized various Java Language Specifications.
>
> That's interesting, thank you!
>
>> Note that cycles are present in most grammars and perfecly fine. The
>> only problematic cycles are the left-recursive ones for recursive
>> descent parsers like ANTLR or PetitParser. Even then you can simply
>> fix the problem by adding a memoizer into the offending cycle, but
>> that yields a very slow grammar. You can find offending cycles with
>> the message #cycleSets from the PetitAnalyzer package.
>
> I tried using the "cycle" tab in the PetitParser GUI, which -I think-
> does the same thing. Knowing how to call it programmatically is even
> better ;)
>
> Alberto
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> this is really nice to have a full java parser for moose... even if  
> the problem after will be a
> semantics analysis.
>
> Stef
>
> On Aug 3, 2010, at 2:39 PM, Alberto Bacchelli wrote:
>
>> On 8/3/10 2:14 PM, Lukas Renggli wrote:
>>> Hi Alberto,
>>>
>>> This is great news. Maybe you also want to post the repository  
>>> URL? :-)
>>
>> Sure, please don't be too much horrified by the quality of the code:
>>
>> http://www.squeaksource.com/PetitJava.html
>>
>>> For what you noticed on bogus grammar specifications check out the
>>> work of Vadim Zaytsev (http://mobile.twitter.com/grammarware). Among
>>> others he analized various Java Language Specifications.
>>
>> That's interesting, thank you!
>>
>>> Note that cycles are present in most grammars and perfecly fine. The
>>> only problematic cycles are the left-recursive ones for recursive
>>> descent parsers like ANTLR or PetitParser. Even then you can simply
>>> fix the problem by adding a memoizer into the offending cycle, but
>>> that yields a very slow grammar. You can find offending cycles with
>>> the message #cycleSets from the PetitAnalyzer package.
>>
>> I tried using the "cycle" tab in the PetitParser GUI, which -I think-
>> does the same thing. Knowing how to call it programmatically is even
>> better ;)
>>
>> Alberto
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev