Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-01-10

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

All times shown according to UTC.

Time Nick Message
06:52 ronsavage joined #marpa
08:30 koo5 joined #marpa
09:09 basiliscos joined #marpa
09:20 lwa joined #marpa
09:42 sirdancealot joined #marpa
10:44 sirdancealot joined #marpa
11:09 koo5 joined #marpa
12:22 ernimril joined #marpa
12:44 sirdancealot joined #marpa
13:13 basiliscos joined #marpa
15:55 jeffreykegler joined #marpa
15:55 jeffreykegler I uploaded Marpa-R2 2.102000 to CPAN.
15:56 jeffreykegler It's an indexed, stable release, identical except for version info to the previous developer's release.
15:56 jeffreykegler Value added is large number of doc and diagnostic fixes.
15:57 jeffreykegler Your testing is appreciated!
16:00 * jeffreykegler abruptly switches topics
16:01 jeffreykegler I've been thinking about discard events, and their use case, and would like some feedback.
16:02 jeffreykegler Discard events, if implemented, would produce discard token information during the parse, in some sort of structure created by the user, presumably an array.
16:03 jeffreykegler The other parse information would typically be produced afterwards, and typically will be in the form of an AST.
16:04 jeffreykegler That is to say, you'll be getting discard tokens and everything else in two different forms at 2 different times.
16:04 jeffreykegler (An exception might be if you're using an event-driven approach to parsing, but I consider that the exception.)
16:05 jeffreykegler You could unite the two in post-processing by traversing the AST left-to-right, and at the same time traversing the discard array left to right, adding its contents to the AST.
16:06 jeffreykegler (Both would need to have location information to keep this dual traversal in sync.)
16:07 jeffreykegler The point here is to alert folks to the fact that discard events will *not* automatically produce an AST with discard token information on it --
16:07 jeffreykegler you'll either have to be content to process the discard information at "event time", ...
16:07 jeffreykegler or combine the two kinds of data yourself.
16:08 jeffreykegler I'd like folks to comment on this, particularly with reference to their foreseen and/or intended applications for discard events.
16:34 rns joined #marpa
17:00 rns re discard events -- my take is that it should be an ordinary event, where handler can call all methods accessible for other events, like span(), location(), literal() etc. IIRC their names.
17:00 rns The application then will be able to save rule/token lhs, start, length and literal of such discarded node -- as was initally requested -- https://groups.google.com/d/msg/marpa-parser/ZIZ003_GUig/3ti4II8HRrgJ -- and save the preceding node by calling last_completed('target').
17:00 rns Further use of such saved data will be up to the application, e.g. in the semantics by checking if the node's lhs and location precede a discarded node and acting appropriately.
17:00 rns If the application needs the discarded nodes in the AST, a special AST walk will be needed to insert the saved discard nodes. I can see that rewriting the grammar to include comments can be simpler and perhaps more efficient in some cases. However, if the application needs kust to save e.g. comments parse data, discard = 'event' looks useful.
17:00 rns Once concern is that discard = 'event' should be set on per-lexeme basis rather than globally, e.g. :discard lexeme => 'event' -- as raising an event for e.g. every discarded whitespace when the app needs to save only discarded comments into doesn't look efficient.
17:07 rns Have to go AFK, will backlog.
17:07 rns left #marpa
17:08 jeffreykegler About to go AFK myself.
17:10 jeffreykegler re http://irclog.perlgeek.de/marpa/2015-01-10#i_9914997 -- last_completed() would be of limited use here -- you would need to know the LHS of the completed node, plus there are lots of corner cases
17:11 jeffreykegler And, yes, discard events will be settable on a per-discard-symbol basis.
19:37 jdurand joined #marpa
19:39 jdurand Re http://irclog.perlgeek.de/marpa/2015-01-10#i_9914856 - what about limiting discard event to event-driven approach, i.e. have discard information available only in terms of $slr->event() ? Unless I misunderstood the point, though - I am backlogging quickly, lack of time today -;
20:32 jeffreykegler joined #marpa
20:35 jeffreykegler Basically that ("discard information available only in terms of $slr->event()") is what I propose to do ---
20:36 jeffreykegler I made the remarks I did because I realized that some readers may have been expecting more integration of discard information with the normal parse tree.
20:38 jeffreykegler I thought some folks might revise their opinion of the need for "discard events" when they realized that an AST integrated with the discard information would not *automatically* be created.
20:39 * jeffreykegler switches to an administrative topic.
20:40 jeffreykegler I just queued Marpa::PP and Marpa::HTML for deletion from CPAN.
20:40 jeffreykegler This was announced back on Nov. 4.  The delay was to allow a dependant module time to make the necessary revisions.
22:21 basiliscos joined #marpa
23:26 ronsavage joined #marpa

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