Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-05-10

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

All times shown according to UTC.

Time Nick Message
01:32 idiosyncrat Demat!
01:49 ilbot3 joined #marpa
01:49 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Code paste: 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 - Youtube channel: https://www.youtube.com/channel/UCYKVfGBtfTqbs1JdYq-dc5g
06:38 sirdancealot joined #marpa
14:55 idiosyncrat joined #marpa
15:12 idiosyncrat Multiple $recce->read()'s are not allowed in Marpa::R3 -- I've just tested it.
15:13 idiosyncrat Especially pleaasing -- this was a complicated change, requiring a lot of new & revised logic in many places, but ...
15:15 idiosyncrat the test ran the first time.  It's fun when that happens.  [ And yes I did double-check to see if the success was spurious. :-) ]
15:15 idiosyncrat I'll document this, and create a new (still alpha) release.
15:17 idiosyncrat Essentially, the change is that previously, if you called $recce->read() more than once in a parse series, Marpa::R3 complained -- as of the next release it no longer complains, and does what you expect, adding the text "block" in each read to the input.
15:18 idiosyncrat The macro thing I talked about previously is NOT implemented in this release -- I'll move on to that.
15:56 sirdancealot joined #marpa
17:58 idiosyncrat joined #marpa
18:01 idiosyncrat Looking over the documentation, I realize a better term for what I current called "physical location" (that is, location in the actual input string) might be L0 location.
18:01 idiosyncrat Any comments?
18:29 idiosyncrat Working on the code often makes me rethink the terminology in the docs, and I noticed that, even after the complications introduced by multiple input blocks from multiple $slr->read() calls ...
18:30 idiosyncrat the code doesn't really contain any idea of a "virtual" location.
18:30 idiosyncrat There are the "g1 locations" based on the g1 grammar's lexemes, and there are locations from the point of view of the L0 grammar.
18:31 idiosyncrat The L0 grammar locations are what I had been calling "physical", but since there is no virtual vs. physical distinction in the code ...
18:31 idiosyncrat but instead only a G1 vs. L0 location distinction, ...
18:32 idiosyncrat I think it makes sense to have the docs reflect that.
18:38 idiosyncrat I'm thinking of another change to $recce->read(), which is fairly major.
18:40 idiosyncrat Right now, it always returns the current L0 location.  This makes the test for a successful read to the end of the reading span is something like
18:41 idiosyncrat if ($slr->read(\$input) == length $input) { ... }
18:42 idiosyncrat I wonder if it's not better to have $slr->read() return Perl undef on a successful read to the end of the reading span, so that the test becomes
18:43 idiosyncrat while (defined $slr->read(\$input)) { ... }
18:44 idiosyncrat Note that the "defined" is necessary, because
18:44 idiosyncrat while ($slr->read(\$input)) { ... }
18:45 idiosyncrat would confused an event a location 0 (which is quite possible) with a successful read to the end of the reading span
18:45 idiosyncrat Again, I am very interested in comments.
19:06 idiosyncrat ====
19:10 idiosyncrat Actually, I think I need more coffee -- none of those above loops work.
19:11 idiosyncrat The more I look at this, the more I think the return values from $slr->read() and $slr->resume, as they stand, are not satisfactory.
19:12 idiosyncrat If both returned a Perl true (1) on a successful read to the end of the reading span, and a Perl false (undef) otherwise, that would be easy and intuitive.
19:13 idiosyncrat I think the original choice for return value tried to do too much.

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