Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-07-02

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:12 idiosyncrat Demat!
00:54 ronsavage joined #marpa
01:01 ronsavage JK: Thanx. And re 'pause_before' & 'ok'. Is the following a plausible scenario? (Thinking of your example which inserts the real 'd'.) Pause before, Trigger event. Change input stream in such a way the same or another another event is triggered at the same place, or at a point within the span of the (replaced) token which triggered the original event. Ergo automiatically skipping the original token would not produce the same sequence of eve
01:01 ronsavage Repeat: .... would not produce the same sequence of events.
01:02 ronsavage Of course I'm implying that the 'ok' meant resuming parsing after the input text replacement.
02:32 idiosyncrat ronsavage: One of the things I forbid is triggering another event (for the same recognizer) inside an event handler.  (Events for different recognizers are OK.)
02:33 idiosyncrat Still, there are ways in which the "infinite loop" could be prevented -- one is moving the position in the input stream, which will be allowed.
02:34 idiosyncrat (I've written & tested, but not yet documented, calls that do that.)
02:34 idiosyncrat For that matter, you'll also be allowed to change input blocks inside an event handler, which could certainly avoid the infinite loop.
02:35 idiosyncrat But still most of the time which an user tries "pause before" without the event handler pausing the recognizer, they'll be accidentally writing an infinite loop.
02:37 idiosyncrat If I forbid that, I'll prevent lots of time-consuming errors, and anything the user really wants to do can be done while the recce is paused -- they just lose the "convenience" of doing it in an event handler.
02:39 idiosyncrat For the fancy, complicated stuff, the more automatic mechanisms are treacherous, and the lower level stuff not really much (if any) additional trouble, so I think it's a good idea to for "pause before" events to actually pause the recce and be handled by event-driven logic, instead of a pur callback solution.
02:41 idiosyncrat Note this is similar to the approach I take with Precedenced statements and sequence statements, where nullable symbols are forbidden because figuring out what they imply in those contexts is tricky & treacherous and, if you really do know what you're doing, doing it by hand is quite possible and given the complexity not much (if any) additional trouble.
03:51 ronsavage joined #marpa
03:55 ronsavage JK: OK. Since you've thought this thru, no problem. Q # 1: Is there a specific reason my pause before with a handler did not work? Eg. I needed to call lexeme_read() perhaps?
03:57 idiosyncrat I never looked at the code, but if you needed to read a lexeme at the event location, you were out of luck unless you pause'ed.  Because all the methods that do that are forbidden inside an event handler.
03:57 ronsavage Q # 2: I did not even think of trying to trigger an event when inside the handler, but is this possible: Combine pause before with triggering an event, and the the handler changes the lexeme which trigger the event, so after the handler returns, and the internal parsing resumes, another event is triggered at the same char in the input stream?
03:58 ronsavage OK. But the code ran to completion using pause before. I'm trying to grasp if there is some fundamental mistake I must avoid in future.
04:00 idiosyncrat No.  The handler can't change the lexeme which triggers it -- but it *can* I believe it can de-activate itself in favor of another lower priority event.  This kind of tricky stuff is why I want the apps to do this sort of thing *outside* of the handlers.
04:00 idiosyncrat "Fundamental mistake" -- if there is I don't see it.
04:01 idiosyncrat It's just that "pause before" is tricky and as we discovered its implications in the new callback-driven mechanism were not 100% foreseen even by me.
04:07 ronsavage OK. I harp on pause before because I always used it. I'll prefer pause after from now on, after I reprogram my poor old brain :-).
04:09 ronsavage Sill harping: I just assumed that pause before would work, and I assumed that when it didn't I needed to 'do something' to get parsing back on track (from my code's point of view).
04:09 ronsavage AFK
04:11 idiosyncrat Yeah.  "pause before" is an oddball.  All the other events, trigger location == event location.  Not "pause before".  It kinda backtracks.
04:11 idiosyncrat Maybe there's a cool way to wrap it in a callback-driven model that I've missed, but right now I don't see it.
04:11 idiosyncrat In any case, it was always to be avoided in favor of "pause after" when that was possible.
04:12 idiosyncrat but that's not always possible/convenient because one very real difference -- when "pause after" triggers, that lexeme has already been read and there is no undoing it.
04:13 idiosyncrat When the "pause before" lexeme event triggers, its lexeme has *not* yet been recognized (and above I should have said recognized instead of "read") ...
04:13 idiosyncrat meaning that you get to re-decide the whole matter.
05:26 ronsavage joined #marpa
05:29 ronsavage I don't mind pause after. To my way of thinking its a bit labourious in that I just need to trigger a different event (name) for each lexeme, so I know which lexeme was read. So, next Q: Will there be a new method to retrieve the id/name/value of the lexeme just read, or is some existing method recommended?
05:30 ronsavage Especially since pause_span() is biting the dust.
05:32 idiosyncrat It could be in the data for the event -- I considered adding it.
05:33 idiosyncrat But why not different events for each lexeme?  I was thinking the name of the lexeme would be obvious from the event name --
05:33 idiosyncrat that is, it isn't necessarily so, but the app writer can make it so if it's important to them.
05:34 idiosyncrat Are separate event names for different lexemes inconvenient in one of your apps?
05:39 idiosyncrat AFK?
05:39 idiosyncrat AFK (question mark was unintended)
06:09 ronsavage So far I've always preferred to have a different event for each different lexeme. I was just wondering about the case of a grammar with a huge number of lexemes :-).
06:10 ronsavage And I'm quite happy to continue maintaining the nexus 1 lexeme == 1 event. It can however lead to a bit of repitition in the code.
06:12 ronsavage And here's a comment in most of my grammars:
06:12 ronsavage # Policy: Event names are always the same as the name of the corresponding lexeme.
07:21 ronsavage joined #marpa
14:33 ilbot3 joined #marpa
14:33 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Code paste/run: https://f.perlbot.pl/#marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today - Youtube channel: https://www.youtube.com/channel/UCYKVfGBtfTqbs1JdYq-dc5g
14:35 ilbot3 joined #marpa
14:35 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Code paste/run: https://f.perlbot.pl/#marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today - Youtube channel: https://www.youtube.com/channel/UCYKVfGBtfTqbs1JdYq-dc5g
16:50 idiosyncrat ronsavage: re https://irclog.perlgeek.de/marpa/2017-07-02#i_14815107 -- I'll leave this one up to you.  If you want the lexeme ID in the event data for lexeme events, I'll add it.
16:52 idiosyncrat Oops!  It's already documented as in there -- http://search.cpan.org/~jkegl/Marpa-R3/pod/Event.pod#Pre-lexeme_events
16:52 idiosyncrat and http://search.cpan.org/~jkegl/Marpa-R3/pod/Event.pod#Post-lexeme_events
16:52 idiosyncrat I forgot that I'd added it.
18:19 sirdancealot joined #marpa
18:23 idiosyncrat https://github.com/jeffreykegler/Marpa--R3/commit/a673813d1041251db3f15bd00fe57d3f5de28639
18:24 idiosyncrat I fixed the Events.pod example for the most general method -- my original version failed in the case where 2 events with the same name occur at the same location.  The original version hashed the events by event name.
18:25 idiosyncrat The new version uses an array (by position) of arrays of events, and is therefore renamed the AoA (arrays of arrays) method.
18:26 idiosyncrat The commit is not terribly stable, but you can read the new Events.pod on Github: https://github.com/jeffreykegler/Marpa--R3/blob/master/cpan/pod/Event.pod#per-location-event-processing-using-an-aoa
22:26 ronsavage joined #marpa
22:30 ronsavage JK: Thanx.
23:28 ronsavage Announce! I've started the Kollos FAQ: http://savage.net.au/Perl-modules/html/kollos.faq/faq.html.

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary