30 Sep
2011
30 Sep
'11
11:53 a.m.
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
4 Oct
4 Oct
8:09 a.m.
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:
--
www.tudorgirba.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
10:05 a.m.
Hi,
Am 04.10.2011 um 08:09 schrieb Tudor Girba:
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.
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
4928
days inactive
4934
days old
3 comments
2 participants
participants (2)
-
Norbert Hartl -
Tudor Girba