Discard events -- a design document

[Jeffrey Kegler]

I've written a design document for "discard events" -- events generated when a token is discarded.  These come out of a discussion on this group, and on the IRC channel.  Your feedback and input is appreciated.

-- jeffrey

[Ron Savage]

(1)

I like having an event interface to discarding, but for people using the action style, how to they access discards?

(2)

[During event processing]: Without a pause clause, how I do retrieve the text discarded?

[Jeffrey Kegler]

Discard events will be named events, accessible via the $recce->events() mechanism.

--
You received this message because you are subscribed to the Google Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeffrey Kegler]

@Ron: I added some clarifications on points (I hope) relevant to your question to the design document.

[Ron Savage]

Yes, thanx. That's good.

From this part of your doc:

:discard ~ ws event => 'wsdiscard'=off

:discard ~ <ws> event => wsdiscard=on

:discard ~ ws event => 'wsdiscard'

Can I assume:

(3) If I wanted to discard 2 different tokens (say: #-style comments and //-style comments), I could attach 2 events with different names to these 2 cases?

(4) Since (pre-existing) events can already be turned on and off with activate(), will this new type of event be controllable likewise?

(5) And thus: Is the '=on', '=off', syntax an extension proposed for all events?

Lastly, my original point (1) makes me think an action needs to be attachable to discards. Is that true, or have I missed the equivalent mechanism in your doc?

[Jeffrey Kegler]

(3) yes to distinquish the two discard events you give them different names -- that is the only way to do it.

(4) the reason for the new mechanism is that, previously, there was no way to turn off an event intially, so that it was always active at location 0.  This could be worked around, but it's a coding nuisance, and that's why I created all this initialization apparatus.  The activate() method still works, and is what you'll use after location 0.

(5) It would make sense for all events, but for now it will only be available for discard events.

(1) revisited -- there is no action for discard events -- you catch discard events coming out of read() or resume(), the same way you catch the others, and at that point do what you like with it.  It may seem weird, because discard events aren't associated with real parse locations, and there could be a lot of them for every undiscarded token.  But tracing already works much like this and I expect it to work fine.

[Ron Savage]

Excellent. Thanx!

[Durand Jean-Damien]

Jeffrey,

Very good. This will adress Zeev's need. I'll probably reinsert comments in the AST as an post-value processing.

Many thanks, JD.

[Zeev Atlas]

Thank you guys...

I am much slower then you and it will take me time to get there (still on the stiff learning curve :), but I guess that with that and with Durand usage of that stuff, I can do a lot.  The design paper seems to address everything that I could have thought about, and the potential of adding such functionality to existing events (perhaps pre-lexeme, post-lexeme) may address my other concerns as well.  Comparing that to the primitive, home grown, partially manual and heavily regex oriented methods that I've used in the past, this is like dream comes true.

ZA

[Ron Savage]

A dream from which we never have to wake!