2015-04-02 11:49 GMT+02:00 p...@highoctane.be <p...@highoctane.be>:
> Sure works.
>
> Regex
>
> '((XXX Logical Channel) ([0-9])) on (((Upstream)|(Downstream)) ([0-9])) on
> ((chassis) ([0-9])), ((slot) ([0-9])), ((mac) ([0-9]))' asRegex
>
> But in PP, things were more comple and there were a lot of them, so:
>
> line
> ^ temperatureStatusDescrEntry token asParser
> / temperatureStatusValueEntry token asParser
> / temperatureThresholdEntry token asParser
> / temperatureLastShutdownEntry token asParser
> / temperatureStateEntry token asParser
> and things like
>
> temperatureStatusDescrEntry ^ temperatureStatusDescrOidPrefix, oidIndex,
> space, equals, space, stringType, space, displayStringValue.
>
> made my day much easier.
>
> Especially when I had all the tokens I needed:
>
> gauge32Type ^'Gauge32:' asParser flatten ==> [:str | #gauge32].
>
>
> Not sure it would have been as flexible with a SmaCC (I am not familiar
> with SmaCC but used Lex/Yacc|Bison in another life).
>
SmaCC is a lot (and I mean a lot) simpler than Flex/bison, especially for
the interaction between Flex and Bison (in short, SmaCC infer all the
token/keyword stuff as well as the api between the two objects, behaving
like a scannerless system).
For everything like keywords, for example, you don't even bother with the
token:
Gauge32Type: "Gauge32:" { #gauge32 } ;
And of course you would:
TemperatureStatusDescrEntry : TemperatureStatusDescrOidPrefix OidIndex
Space "=" Space StringType Space DisplayStringValue
(Everytime I read PetitParser code, I see the SmaCC grammar, usually in a
more verbose form (asParser, asToken)... )
Some of the benefits of SmaCC are not that obvious in fact. Coming from the
Flex/Bison world, what is striking is the multithreading ability of the
SmaCC parser infrastructure: they have no global/shared space and you can
create as many instances of them as you like, as often as you like... A
second benefit, but harder to use, is the AST node automatic generation,
with the api, an equality and visitors: this makes all the code appearing
behind an SmaCC parser very regular.
However, if you derive on a regular basis grammars, the SmaCC API is not
designed for that. It could do it (you could maybe include other grammars,
for example), but nobody has expressed that need :)
Thierry
