2015-04-02 11:49 GMT+02:00 phil@highoctane.be <phil@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