Petit Puzzle
Locked
 
|
Hi,
I want to ask if there is a elegant solution for the following problem: In my grammar there are references (symbols/names that reference entities somewhere). One is Syntax>>typeReference ^ self failOnReservedWords: ( #uppercase asParser, (#word asParser plus separatedBy: $- asParser) optional ) flatten These typeReferences can be standalone tokens (parsed with a token parse class that parses whitespaces and comments) Syntax>>reference ^ typeReference asn1Token / valueReference asn1Token / ... with PPParser>>asn1Token ^ (ASN1TokenParser on: self) ==> [:node| node value] or embedded in another type Syntax>>valueSetFieldReference ^ $& asParser, typeReference If have two classes, one for the syntax and for the parsing into model objects. Every typeReference should be parsed in the parser class to Parser>>typeReference ^ super typeReference ==> [:node| ASN1ReferenceNode new name: node ] The problem is that it is hard to have the typeReference be tokenized or not and make sure they are all parsed to the ASNReferenceNode. The example above Syntax>>reference ^ typeReference asn1Token / valueReference asn1Token / ... does not work because typeReferences result is transformedd to the model class but the asn1Token applied afterwards gives back a string again. I tried having a second parser typeReferenceToken but that only works if I double the code of typeReference in syntax and parser class. And as I am running short of instance variables I would prefer a solution without having the need for creating new instance variables. Any ideas? I hope I could explain the problem enough to get you the context you need, Norbert _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
I think I understand your problem. First, I would only use asn1Token in the Parser class because you want the grammar to be as flexible as possible (even if sometimes appears as an over-complication, it somehow proved to be always a good idea in the long run). The cleanest solution is to rely on a new instance variable to distinguish between cases with or without tokenizing. If you hit the limit, you can create an intermediate SyntaxExtension class that can store this. It is not ideal, but I think it solves the problem. Another solution would be to externalize a part of the parser to another class. Cheers, Doru On 30 Sep 2011, at 11:53, Norbert Hartl wrote: > Hi, > > I want to ask if there is a elegant solution for the following problem: > > In my grammar there are references (symbols/names that reference entities somewhere). One is > > Syntax>>typeReference > ^ self failOnReservedWords: ( > #uppercase asParser, > (#word asParser plus separatedBy: $- asParser) optional > ) flatten > > These typeReferences can be standalone tokens (parsed with a token parse class that parses whitespaces and comments) > > Syntax>>reference > ^ typeReference asn1Token / valueReference asn1Token / ... > > with > > PPParser>>asn1Token > ^ (ASN1TokenParser on: self) ==> [:node| node value] > > or embedded in another type > > Syntax>>valueSetFieldReference > ^ $& asParser, typeReference > > If have two classes, one for the syntax and for the parsing into model objects. Every typeReference should be parsed in the parser class to > > Parser>>typeReference > ^ super typeReference ==> [:node| > ASN1ReferenceNode new name: node ] > > The problem is that it is hard to have the typeReference be tokenized or not and make sure they are all parsed to the ASNReferenceNode. The example above > > Syntax>>reference > ^ typeReference asn1Token / valueReference asn1Token / ... > > does not work because typeReferences result is transformedd to the model class but the asn1Token applied afterwards gives back a string again. I tried having a second parser typeReferenceToken but that only works if I double the code of typeReference in syntax and parser class. And as I am running short of instance variables I would prefer a solution without having the need for creating new instance variables. > > Any ideas? > > I hope I could explain the problem enough to get you the context you need, > > Norbert > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
Am 04.10.2011 um 08:09 schrieb Tudor Girba: > Hi, > > I think I understand your problem. First, I would only use asn1Token in the Parser class because you want the grammar to be as flexible as possible (even if sometimes appears as an over-complication, it somehow proved to be always a good idea in the long run). The cleanest solution is to rely on a new instance variable to distinguish between cases with or without tokenizing. > I'm not sure if I understand you. The asn1Token does two things: It trims the parsed thing and it can ignore comments. Both are grammar dependent. In my example where I could have &Symbol the whitespace between & and Symbol is not valid (nor is a comment of course). Taking this into account and assume that your reasoning still applies I would want to know the rationale of what makes a syntax class and what makes a parser class. I'm doing it in a way that the syntax class reflects the grammar exactly. The parser class on top would be the builder class for the model representation you want to build from the grammar. As a side note: In the syntax class I used to do things like this anotherRule ^ ${ asParser trim, someRule, $} asParser trim ==> [:nodes| nodes second] but now I'm not sure if the ==> extension is a good thing to do. Second about the instance variable statement. Basically it is more clean to have two separate instance variables. But if one parser is derived from the other like the tokenized one it is not that clean at all. You have someRule ^ anything asParser someTokenizedRule ^ someRule asn1Token But that does not work that good. I can have either delegation of the rules (someTokenizedRule calling someRole) _or_ I can have them extended in a derived parser class. Both is not that easy to achieve. So I didn't really get the rationale behind your reasoning but I can instantenous see it will solve part of the problem. > If you hit the limit, you can create an intermediate SyntaxExtension class that can store this. It is not ideal, but I think it solves the problem. > Can you elaborate on that? > Another solution would be to externalize a part of the parser to another class. > I've done this but it is not advizable. It is hard to use the petit parser gui then, parsers are multiplied. I invested some time to reduce the rules of the parser just to get all into the same class and it is much better now. Well, I have 252 vars by now again. thanks, Norbert > On 30 Sep 2011, at 11:53, Norbert Hartl wrote: > >> Hi, >> >> I want to ask if there is a elegant solution for the following problem: >> >> In my grammar there are references (symbols/names that reference entities somewhere). One is >> >> Syntax>>typeReference >> ^ self failOnReservedWords: ( >> #uppercase asParser, >> (#word asParser plus separatedBy: $- asParser) optional >> ) flatten >> >> These typeReferences can be standalone tokens (parsed with a token parse class that parses whitespaces and comments) >> >> Syntax>>reference >> ^ typeReference asn1Token / valueReference asn1Token / ... >> >> with >> >> PPParser>>asn1Token >> ^ (ASN1TokenParser on: self) ==> [:node| node value] >> >> or embedded in another type >> >> Syntax>>valueSetFieldReference >> ^ $& asParser, typeReference >> >> If have two classes, one for the syntax and for the parsing into model objects. Every typeReference should be parsed in the parser class to >> >> Parser>>typeReference >> ^ super typeReference ==> [:node| >> ASN1ReferenceNode new name: node ] >> >> The problem is that it is hard to have the typeReference be tokenized or not and make sure they are all parsed to the ASNReferenceNode. The example above >> >> Syntax>>reference >> ^ typeReference asn1Token / valueReference asn1Token / ... >> >> does not work because typeReferences result is transformedd to the model class but the asn1Token applied afterwards gives back a string again. I tried having a second parser typeReferenceToken but that only works if I double the code of typeReference in syntax and parser class. And as I am running short of instance variables I would prefer a solution without having the need for creating new instance variables. >> >> Any ideas? >> >> I hope I could explain the problem enough to get you the context you need, >> >> Norbert >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > > _______________________________________________ > 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 |
|
|
Doru,
I'm very interested if you have some additional information that I requested in the last mail. Just nagging :) Norbert Am 04.10.2011 um 10:05 schrieb Norbert Hartl: > Hi, > Am 04.10.2011 um 08:09 schrieb Tudor Girba: > >> Hi, >> >> I think I understand your problem. First, I would only use asn1Token in the Parser class because you want the grammar to be as flexible as possible (even if sometimes appears as an over-complication, it somehow proved to be always a good idea in the long run). The cleanest solution is to rely on a new instance variable to distinguish between cases with or without tokenizing. >> > I'm not sure if I understand you. The asn1Token does two things: It trims the parsed thing and it can ignore comments. Both are grammar dependent. In my example where I could have &Symbol the whitespace between & and Symbol is not valid (nor is a comment of course). Taking this into account and assume that your reasoning still applies I would want to know the rationale of what makes a syntax class and what makes a parser class. > I'm doing it in a way that the syntax class reflects the grammar exactly. The parser class on top would be the builder class for the model representation you want to build from the grammar. As a side note: In the syntax class I used to do things like this > > anotherRule > ^ ${ asParser trim, someRule, $} asParser trim ==> [:nodes| nodes second] > > but now I'm not sure if the ==> extension is a good thing to do. > > Second about the instance variable statement. Basically it is more clean to have two separate instance variables. But if one parser is derived from the other like the tokenized one it is not that clean at all. You have > > someRule > ^ anything asParser > > someTokenizedRule > ^ someRule asn1Token > > But that does not work that good. I can have either delegation of the rules (someTokenizedRule calling someRole) _or_ I can have them extended in a derived parser class. Both is not that easy to achieve. > So I didn't really get the rationale behind your reasoning but I can instantenous see it will solve part of the problem. > >> If you hit the limit, you can create an intermediate SyntaxExtension class that can store this. It is not ideal, but I think it solves the problem. >> > Can you elaborate on that? > >> Another solution would be to externalize a part of the parser to another class. >> > I've done this but it is not advizable. It is hard to use the petit parser gui then, parsers are multiplied. I invested some time to reduce the rules of the parser just to get all into the same class and it is much better now. Well, I have 252 vars by now again. > > thanks, > > Norbert >> On 30 Sep 2011, at 11:53, Norbert Hartl wrote: >> >>> Hi, >>> >>> I want to ask if there is a elegant solution for the following problem: >>> >>> In my grammar there are references (symbols/names that reference entities somewhere). One is >>> >>> Syntax>>typeReference >>> ^ self failOnReservedWords: ( >>> #uppercase asParser, >>> (#word asParser plus separatedBy: $- asParser) optional >>> ) flatten >>> >>> These typeReferences can be standalone tokens (parsed with a token parse class that parses whitespaces and comments) >>> >>> Syntax>>reference >>> ^ typeReference asn1Token / valueReference asn1Token / ... >>> >>> with >>> >>> PPParser>>asn1Token >>> ^ (ASN1TokenParser on: self) ==> [:node| node value] >>> >>> or embedded in another type >>> >>> Syntax>>valueSetFieldReference >>> ^ $& asParser, typeReference >>> >>> If have two classes, one for the syntax and for the parsing into model objects. Every typeReference should be parsed in the parser class to >>> >>> Parser>>typeReference >>> ^ super typeReference ==> [:node| >>> ASN1ReferenceNode new name: node ] >>> >>> The problem is that it is hard to have the typeReference be tokenized or not and make sure they are all parsed to the ASNReferenceNode. The example above >>> >>> Syntax>>reference >>> ^ typeReference asn1Token / valueReference asn1Token / ... >>> >>> does not work because typeReferences result is transformedd to the model class but the asn1Token applied afterwards gives back a string again. I tried having a second parser typeReferenceToken but that only works if I double the code of typeReference in syntax and parser class. And as I am running short of instance variables I would prefer a solution without having the need for creating new instance variables. >>> >>> Any ideas? >>> >>> I hope I could explain the problem enough to get you the context you need, >>> >>> Norbert >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Problem solving should be focused on describing >> the problem in a way that makes the solution obvious." >> >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |