6 Oct
2011
6 Oct
'11
12:05 p.m.
I have just watched video of Tudor's great hands on PettitParder tutorial on
ESUG, and few questions poped up to me.
1. in PPMSEGrammar, start is encoded ad ^elements end
is that a good habit to include end in start method? Somehow this is counter
intuitive to me since it seems it would make such grammar non embeddable in
another parser, or I am mistaken?
2. can ==> be cascaded in a sense that if we have parser A, its subclass
parser B which calls supper and then adds ==>. Can we then have C which is
subclass of B, and adds its ==> on top of the one added by B?
3. What do you think, could PettitParser be reasonably used to de-marshal
some (binary) network protocol. By reasonably I mean that it would not be an
order of magnitude slower than some code hacked from the scratch (but not
terribly optimized).
--
View this message in context:
http://forum.world.st/a-few-Pettit-questions-tp3877633p3877633.html
Sent from the Moose mailing list archive at Nabble.com.
6 Oct
6 Oct
6:45 p.m.
1. in PPMSEGrammar, start is encoded ad ^elements end
is that a good habit to include end in start method? Somehow this is counter
intuitive to me since it seems it would make such grammar non embeddable in
another parser, or I am mistaken?
Yeah, I think this is like a pattern. #start is just the default
production when the parser is used standalone. When you compose it
with some other parser you could directly go with whatever other
production you want, i.e.
PPMSEGrammar new elements
2. can ==> be cascaded in a sense that if we have
parser A, its subclass
parser B which calls supper and then adds ==>. Can we then have C which is
subclass of B, and adds its ==> on top of the one added by B?
It is always cascaded. #==> just wraps the receiver with the action
block, so if you write
p := (#word asParser
==> [ :each | each asUppercase ])
==> [ :each | each asciiValue ].
p parse: 'a' --> returns 65, the ascii code of $A
3. What do you think, could PettitParser be reasonably
used to de-marshal
some (binary) network protocol. By reasonably I mean that it would not be an
order of magnitude slower than some code hacked from the scratch (but not
terribly optimized).
Definitely. You would probably need to implement some special stream
that works on the bit-level. Marcus and I once started to write a
bytecode decompiler, that worked reasonably well but I don't know the
status.
An optimized hand written parser is certainly faster. For performance
I typically compare the hand written parser of the refactoring engine
(RBParser) and the strictly equivalent one in PetitParser
(PPSmalltalkParser). The hand written one is about 3.3 times faster.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
6:46 p.m.
Am 06.10.2011 um 12:05 schrieb drush66:
I have just watched video of Tudor's great hands
on PettitParder tutorial on
ESUG, and few questions poped up to me.
1. in PPMSEGrammar, start is encoded ad ^elements end
is that a good habit to include end in start method? Somehow this is counter
intuitive to me since it seems it would make such grammar non embeddable in
another parser, or I am mistaken?
To use end in the start method is just saying that you want to consume all of the
input with your rule. Let's say you have "mainrule end" in your start of the
grammar then you can embed this in another grammar by referencing mainrule (and not start)
in the new grammar. In the new grammar you would have start defined as
"anothermainrule end". The start method is just to one that is used by default.
2. can ==> be cascaded in a sense that if we have
parser A, its subclass
parser B which calls supper and then adds ==>. Can we then have C which is
subclass of B, and adds its ==> on top of the one added by B?
Yes. As input to the ==> block who will get the result of the ==> block of
B
3. What do you think, could PettitParser be reasonably
used to de-marshal
some (binary) network protocol. By reasonably I mean that it would not be an
order of magnitude slower than some code hacked from the scratch (but not
terribly optimized).
I can only assume that the produced overhead is some magnitude slower than hand written
stream parsers. But I'm sure there will be answers with more insight coming.
Norbert
4609
days inactive
4609
days old
2 comments
3 participants
participants (3)
-
drush66 -
Lukas Renggli -
Norbert Hartl