Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-08-29

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

All times shown according to UTC.

Time Nick Message
00:00 idiosyncrat_ re http://irclog.perlgeek.de/m​arpa/2015-08-28#i_11132433
00:01 idiosyncrat_ Actually, the recognizer has no idea when the end of virtual input will occur, because the user can keep extending it.
00:02 idiosyncrat_ CQ: EOF is entirely a concept defined by you the user, and it is up to your logic to determine where that is, and what to do about it.
00:02 idiosyncrat_ A recognizer will, if the grammar allows, keep accepting input forever.
00:03 idiosyncrat_ Ron: exhaustion is a related concept but not quite the same.  It may be after a certain point, the grammar just cannot continue, and then the parse is said to be exhausted.
00:03 idiosyncrat_ This may happen at the end-of-virtual-input, before it, or never.
00:04 idiosyncrat_ Exhaustion before the end-of-virtual input is typically considered a parse error, but that is far from always the case.
00:06 idiosyncrat_ If your grammar is imitating regular expressions, for example, exhaustion while there is still unread input, if there was a "match" (that is, a successful parse) will usually be considered a "success".
00:07 idiosyncrat_ As s bit of history of this matter --
00:07 idiosyncrat_ historically, parsers were supposed to consume all an input, and anything else was a failure.
00:08 idiosyncrat_ when regular expressions came along, they brought in a different set of assumptions about relationship of the "match" (= "parse") to the input.
00:09 idiosyncrat_ When I had to combine all this for Marpa, I wondered if I was the first person ever to have to sort all of this out, but ...
00:10 idiosyncrat_ Grune & Jacobs, 2nd ed, p. 93 in a section very nicely entitled "When are we done parsing?"
00:11 idiosyncrat_ sort all of this out, to the extent it can be, in 2 pages, including two tables of alternatives.
00:12 idiosyncrat_ Their conclusion is worth noting:
00:12 idiosyncrat_ "Since there is no clear-cut general criterion for termination in directional parsers,
00:12 idiosyncrat_ each parse comes with its own stopping criterion,
00:12 idiosyncrat_ a somewhat undesirable state of affairs."
00:15 idiosyncrat_ Some users have been perplexed about how Marpa handles end-of-input, because in the context of their particular application, it seems like Marpa is being a bit dense about things.
00:16 idiosyncrat_ But Marpa's interface is a compromise which has proven to work reasonably well for parsers whose ideas of end-of-input vary widely from each other.
03:04 CQ_ joined #marpa
03:55 mauke_ joined #marpa
04:17 rns lwa: re http://irclog.perlgeek.de/m​arpa/2015-08-28#i_11135165 -- yes and textual inclusion worked for me (I used it for extension of Lua grammar with BNF statements), because Marpa is good at error diagnostics that allows correction. Also, textual inclusion can be said to have been working for years in C and other programming languages. :)
04:17 rns \include could be used with \namespace to import subgrammars into the specified grammar namespace for modularization, reusability, extensibility, etc., experimentation -- quickly turn on an off parts of the grammar, perhaps conditionally with \if \then \else.
04:18 rns There was a talk a couple of years ago about include directive for SLIF on marpa-parser mailing list and/or, IIRC, on this channel, so you Preprocessor re-ignited the thought.
07:49 ronsavage joined #marpa
07:53 ronsavage jk: Re http://irclog.perlgeek.de/m​arpa/2015-08-29#i_11135960. Aaagghh.
08:07 lwa joined #marpa
11:31 koo8 joined #marpa
11:48 ronsavage joined #marpa
13:25 ernimril joined #marpa
13:25 koo8 joined #marpa
13:39 mvuets joined #marpa
13:40 mvuets hi! another Marpa-powered talk done! this time - more (just a little) code, examples, and theory
14:55 idiosyncrat_ joined #marpa
14:55 idiosyncrat_ mvuets: Great!
14:55 idiosyncrat_ Was there video this time?
14:58 mvuets nope )-:
14:59 mvuets but i made slides this time (-:
14:59 mvuets plan to put them together with notes in a week or two
14:59 mvuets i reckon i want to give this talk yet another time
15:07 ernimril mvuets, are the slides public?
15:13 mvuets not yet, but will be
15:16 idiosyncrat_ https://github.com/mvuets/talk-processing-toki-po​na-with-perl/blob/master/demo/parser/tokipona.bnf
15:17 idiosyncrat_ The Toki Pona BNF
15:17 idiosyncrat_ Too bad about no video, though.
15:37 idiosyncrat_ Looking forward to the slides.
15:37 idiosyncrat_ mvuets: Congratulations!
15:38 idiosyncrat_ AFK
18:23 jdurand joined #marpa
18:24 jdurand Jeffrey, if a read() or resume() fails, is the recognizer still usable ? I was thinking to try{}/catch|} that and reuse the recce when possible... Thanks
18:47 koo8 joined #marpa
19:33 idiosyncrat_ joined #marpa
19:34 idiosyncrat_ jdurand: it depends on why read the read() or resume() stopped.
19:34 idiosyncrat_ If it's documented as recoverable, then it should be.
19:35 idiosyncrat_ the classic case is MARPA_ERR_UNEXPECTED_TOKEN_ID, which IIRC can be configured to not return an error.
19:36 idiosyncrat_ But, per the docs for marpa_r_alternate() in the libmarpa API:
19:36 idiosyncrat_ "The error codes MARPA_ERR_DUPLICATE_TOKEN, MARPA_ERR_NO_TOKEN_EXPECTED_HERE and MARPA_ERR_INACCESSIBLE_TOKEN also leave the recognizer in a fully recoverable state,
19:36 idiosyncrat_ "and may also be useable for the Ruby Slippers or similar techniques.
19:36 idiosyncrat_ "At this writing, the author knows of no applications which attempt to recover from these errors."
19:41 idiosyncrat_ The SLIF allows Ruby slippers mode for MARPA_ERR_UNEXPECTED_TOKEN_ID
19:42 idiosyncrat_ Reading the code, the SLIF treats MARPA_ERR_NO_TOKEN_EXPECTED_HERE and MARPA_ERR_INACCESSIBLE_TOKEN as errors, so I'd suspect the SLIF does not allow recovery.
19:45 idiosyncrat_ The SLIF XS code does some special handling for MARPA_ERR_DUPLICATE_TOKEN, but I don't know it you can actually recover.
19:45 idiosyncrat_ Duplicate tokens were the one case that I thought there might be useful recovery from.
19:46 idiosyncrat_ Again, if you code directly via libmarpa, you get what marpa_r_alternate() docs suggest
19:48 rns perhaps rejection events -- http://search.cpan.org/~jkegl/Marpa-R2-​2.104000/pod/Event.pod#Rejection_events -- can be used for recovery?
20:23 idiosyncrat_ rns: yes
20:40 rns Good. Found this example -- https://github.com/jeffreykegler/Marp​a--R2/blob/master/cpan/t/sl_bracket.t -- in the test suite.
20:42 mauke_ joined #marpa
21:54 djns joined #marpa
22:28 ronsavage joined #marpa
23:17 jdurand ok, thx to both - THIF interface could be a way in perl if I want to dig directly with that - or C as usual -;

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