Guillermo wrote:
Maybe you can use a -completely separate- pre-parser? :)
It takes the input with the pre processor directives, and answers a new processed string which the original parser will handle?.
Yes, I guess so. I'm fighting a bit with PetitParser, wondering if the traditional style of building parsers wouldn't be faster. But that might be just about trying something new. I like the tests, the separate lexicon, syntax and semantics subclassing not so much better than preprocessing, scanning, parsing. I definitely don't like having 80 productions in a class (growing to 300, not sure how to grow over the max nr of instVars ). Is there an array or dictionary based PPCompositeParser?
Stephan
On 9/14/12, Stephan Eggermont stephan@stack.nl wrote:
Guillermo wrote:
Maybe you can use a -completely separate- pre-parser? :)
It takes the input with the pre processor directives, and answers a new processed string which the original parser will handle?.
Yes, I guess so. I'm fighting a bit with PetitParser, wondering if the traditional style of building parsers wouldn't be faster. But that might be just about trying something new. I like the tests, the separate lexicon, syntax and semantics
subclassing not so much better than preprocessing, scanning, parsing. I definitely don't like having 80 productions in a class
I put them into into method categories and that works very fine for me.
(growing to 300,
not sure how to grow over the max nr of instVars ).
I assume it is not possible to have more than 255 rules in a class but I have not tried this limit yet.
But you can start combining parser as I understand. I have not done this either, so I would appreciate to be pointed to an example.
--Hannes
Is there an array or
dictionary based PPCompositeParser?
Stephan _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Am 14.09.2012 um 14:35 schrieb H. Hirzel hannes.hirzel@gmail.com:
On 9/14/12, Stephan Eggermont stephan@stack.nl wrote:
Guillermo wrote:
Maybe you can use a -completely separate- pre-parser? :)
It takes the input with the pre processor directives, and answers a new processed string which the original parser will handle?.
Yes, I guess so. I'm fighting a bit with PetitParser, wondering if the traditional style of building parsers wouldn't be faster. But that might be just about trying something new. I like the tests, the separate lexicon, syntax and semantics
subclassing not so much better than preprocessing, scanning, parsing. I definitely don't like having 80 productions in a class
I put them into into method categories and that works very fine for me.
(growing to 300,
not sure how to grow over the max nr of instVars ).
I assume it is not possible to have more than 255 rules in a class but I have not tried this limit yet.
I experienced that limit and it is 254 instance variables.
But you can start combining parser as I understand. I have not done this either, so I would appreciate to be pointed to an example
In order to combine parsers you need separate grammar parts that can be combined with a single rule. I think this can be a heavy task if you have a huge grammar and you like to split it into parts. I tried something by having delegating parsers. Meaning putting productions in separate classes and delegate to the parsers inside a production rule. After a while I started to dislike the approach and got rid of the separate classes again. Instead I compacted the rules a bit. Rules that were really close to each other I have combined in one method having the individual rules in temporary variables. Until now I didn't find any better approach. If the project is huge and a lot of extra complexity is ok then using Lukas' approach in Helvetia would be feasible. By introducing a separate smalltalk parser the accesses to instance variables are mapped onto a dictionary. This way the limit isn't there.
Norbert
--Hannes
Is there an array or
dictionary based PPCompositeParser?
Stephan _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
H. Hirzel -
Norbert Hartl -
Stephan Eggermont