I'm new to this fascinating compiler-building-parsing-grammar-lexing-whatnot stuff. I never had compiler building education so a steep learnig curve for me here. Nevertheless, as I already said, it is very fascinating.
I came across this parsing technology because our software parses events from a third party source and we are looking to improve our software. The third party source (hardware) has different firmware levels and therefore sends slightly different events. With our current concept we hit a wall regarding maintainability (too many if's, you know). I don't complain, my expertise secures my job :-)
I thought, since the events come in a more or less defined pattern this is a kind of language and perhaps it is possible to write grammars for every firmware. But, there is the time component. We have to do actions BEFORE everything (from the items objective) is said and done.
Sample Events:
1. NewPallet on conveyor => Action : Insert new pallet in our DB
2. Pallet Checked => Action : Pallet is OK, write it in DB
3. Pallet Stored ==> Action : Pallet is stored
Sample 2:
1. Pallet arrives from store: => Action: Well yes. thanks for noticing me
2. Commisioning 2 parcels from pallet => Action: Update contents of pallet in db
3. Pallet sent to Store: => Action: yes yes...
I did some reading and I'm not sure if that parsing is appropriate. In the samples the input to the parser seems always complete (source files or CSV file or...) but our software must act "before the source is complete" so to say.
Would be nice if someone which has already flown through the thick clouds of parsing complexitiy and has the eagle's overview can give me a tip.
Thanks
Ben
Since ANTLR 4 cannot handle streaming input, you cannot execute actions before the complete input is available. It is only possible to execute actions before the complete input has been parsed.
http://stackoverflow.com/questions/14864777/using-antlr-for-parsing-data-from-never-ending-stream
To really avoid confusion, I’m include the Javadoc for the addParseListener method as well:
Provide a listener that gets notified about token matches, and rule entry/exit events DURING the parse. It's a little bit weird for left recursive rule entry events but it's deterministic. THIS IS ONLY FOR ADVANCED USERS. Please give your ParseTreeListener to a ParseTreeWalker instead of giving it to the parser!!!!
If you have to ask a question about the method, it’s probably not the method you want to use. Ter really wanted to remove this method, but I argued for its inclusion due to some really rare edge cases where it provides a big performance win over separated parsing/walking.
It gets even more weird if you use the @leftfactor{rulename} directive to automatically left-factor rules in a grammar. (This is an experimental feature I added to my optimized branch to address performance problems in GoWorks without rewriting Go.g4 grammar.)
--
Sam Harwell
Owner, Lead Developer
--
You received this message because you are subscribed to the Google Groups "antlr-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
antlr-discussi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I'll get the book and start reading. Hopefully no further shocks there....;-)
Thanks again.
Ben (in busy mode now)