Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-10-28

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

All times shown according to UTC.

Time Nick Message
00:03 ronsavage jeffreykegler: And my own modules. I've released at least 7 versions of various distros this month alone.
00:55 lwa joined #marpa
07:48 ronsavage joined #marpa
08:14 lwa joined #marpa
10:52 hobbs joined #marpa
13:19 ilbot3 joined #marpa
13:19 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Pastebin: http://scsys.co.uk:8002/marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today
15:59 jeffreykegler joined #marpa
18:07 lwa What is the correct way to do external scanning via events in Marpa? When I $r->lexeme_read(…) an externally scanned lexeme, this will prevent internally-scanned ambiguous lexemes from being read at the same G1 position. Saying “events always trump internal scanning” would not be satisfactory:
18:08 lwa (a) this effectively requires me to perform all possibly ambiguous scanning via events, or switching to external scanning completely. This possible involves a reimplementation of a lexeme priority system, and has negative performance implications.
18:08 lwa (b) this (more specifically the event-resetting behaviour of $r->resume) requires me to write a convoluted parsing loop to avoid losing events, like this: `for ($r->read(\$input); $r->pos < length $input; $r->resume) { while (my @events = @{ $r->events }) { my $lexemes_read = handle($r, @events); last if not $lexemes_read } }`.
18:08 lwa Is this a design bug or known limitation in the SLIF, or am I missing an obvious solution?
18:30 jeffreykegler I am not sure I understand the question.
18:31 jeffreykegler Helpful might be looking at the test files that use these techniques in the "master" branch on Github.
18:31 jeffreykegler The two test files are t/sl_salad.t, t/_sl_ruby.t
18:32 lwa OK, I'll look into those, then rephrase my question.
18:32 jeffreykegler There is also, in the main "cpan" directory, bracket.t, in which I am working up something which I hope will be pretty cool.
18:33 jeffreykegler It "runs", but because it's not in a well-defined test framework, it's harder to figure out where I'm going with it.
18:34 jeffreykegler What may be a partial answer: Yes, in the SLIF, events involve calling back to Perl and are relatively expensive.  The cost occurs only when they are used, but they may be often.
18:35 jeffreykegler Note that events can be deactivated and reactivated, so you don't have to pay the price when you aren't expecting any relevant events.
18:36 jeffreykegler A real efficiency solution to the will be one of the by-products of Kollos.
18:38 jeffreykegler I'm not sure I've addressed your question accurately in the above.  Let me know.
19:04 lwa All the test files you mention use the apparently undocumented "rejection" and "exhaustion" named arguments to the Scanless::R constructor. While Ruby Slippers Parsing via rejection events will solve my practical problem, it does not address the issue I tried to raise:
19:04 lwa Assume the input "aa" and the ambiguous grammar ":default ::= action => ::first; String ::= Char+ action => ::array; Char ::= letter_a | extern; letter_a ~ [a]; extern ~ [^\s\S]; event extern = predicted extern" where the event handler for "extern" will match any character, but substitute the value "extern" instead. I am now trying to get the 4 different parse trees [a, a], [a, extern], [extern, a], [extern, extern].
19:05 lwa Now depending on where I $r->resume, I either get two parse trees which both look like [extern, a] or four parse trees which all look like [extern, a, extern, a].
19:08 jeffreykegler Lexemes read at a G1 location must be either all external or all internal.
19:09 jeffreykegler Can what you are trying to accomplish be down by having a new rule "<wrap extern> ::= extern", whose value is always 'extern'?
19:10 jeffreykegler * be down -> be done
19:16 lwa “Lexemes read at a G1 location must be either all external or all internal.” – Unfortunately, this resolves my problem. Is this likely to change in Kollos?
19:16 jeffreykegler Also, I'm not sure about the use of a "predicted" event for <extern> -- these trigger regardless of what follows, which in many contexts means a lot of irrelevant triggers.
19:17 jeffreykegler Change in Kollos?  I don't think so.  Doing both internal and external scanning at one location strikes me as a bit like flying the plane manually, while also having the autopilot active -- lots of potential for confusion.
19:20 jeffreykegler It's very hard for me to think of a problem for which mixing the two kinds of scanning (external/internal) at a single location would be the most elegant solution, though maybe you've found one.
19:24 lwa Well, I'm trying to use Marpa on context-sensitive languages such as Markdown-like formats. While I can express the context-sensitive parts within the event system, it's far from elegant. And that got me thinking, leading to the pathological example outlined above.
19:42 jeffreykegler AFK
22:46 flaviu joined #marpa
23:25 jeffreykegler joined #marpa

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