Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-12-14

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

All times shown according to UTC.

Time Nick Message
00:57 idiosyncrat joined #marpa
01:00 idiosyncrat Demat!
01:01 idiosyncrat Currently at work on a new version of the Abstract Syntax Forests (ASFs).  I'd originally planned to get to this *last*, but as I progress it started to make sense to do it as a stepping stone to other things.
01:03 idiosyncrat In particular, before hacking the DSL grammar, I want to finish refactoring the way the meta-grammar is parsed -- otherwise I wind up writing the same code twice, and the first time having to solve a lot of difficulties which will soon disappear.
01:03 idiosyncrat The new ASFs will become the evaluator for the meta-grammar.
01:04 idiosyncrat Eventually, in fact, I expect all evaluation to be done via the new ASFs, so that the ASFs cease to be an afterthought/add-on and are part of the essential workflow of Kollos/Marpa.
01:05 idiosyncrat As such they will replace the bocage.
02:23 ceridwen_ joined #marpa
02:23 ceridwen_ joined #marpa
02:38 ceridwen_ joined #marpa
02:38 idiosyncrat joined #marpa
02:38 Cheery joined #marpa
02:38 ernimril joined #marpa
02:38 koom joined #marpa
02:38 shadowpaste joined #marpa
02:38 kaare_ joined #marpa
02:38 hobbs joined #marpa
02:38 simcop2387 joined #marpa
02:38 perlbot joined #marpa
02:38 lucs_ joined #marpa
02:38 chansen_ joined #marpa
02:38 iarna joined #marpa
02:38 sivoais joined #marpa
02:38 gabiruh joined #marpa
02:38 KotH joined #marpa
02:59 ilbot3 joined #marpa
02:59 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
04:35 ronsavage joined #marpa
04:36 ronsavage JK: Did you see the backlog for the talk between Cheery and amon?
05:28 ronsavage joined #marpa
05:38 idiosyncrat ronsavage: re https://irclog.perlgeek.de/marpa/2017-12-14#i_15578267 -- thanks for the heads up.
05:43 idiosyncrat Cheery, amon: re https://irclog.perlgeek.de/marpa/2017-12-13#i_15573636
05:43 idiosyncrat Indeed I do try to backlog, but missed this until ronsavage's heads up.  Sorry.
05:44 idiosyncrat The registrations set by registration_init() are memoized in the recognizer's Marpa::R2::Internal::Recognizer::REGISTRATIONS field.
05:48 idiosyncrat In detail, what happens is that the memoization Marpa::R2::Internal::Recognizer::REGISTRATIONS is cleared in registration_init(): https://github.com/jeffreykegler/Marpa--R2/blob/master/cpan/lib/Marpa/R2/Recognizer.pm#L199
05:49 idiosyncrat s/registration_init()/reset_evaluation()/
05:50 idiosyncrat reset_evaluation() is called when a new recognizer is created or when an existing one is reset with Marpa::R2::Recognizer::reset_evaluation()
05:51 idiosyncrat Whenever registrations are needed, the code checks to see if they are memoized in the Marpa::R2::Internal::Recognizer::REGISTRATIONS field.
05:51 idiosyncrat If not, registration_init() is called to populate that field.
05:52 idiosyncrat TL;DR -- registration_init is called whenever reset_evaluation is called, whether a recomputation is really needed or not.
05:53 idiosyncrat As you both conjectured correctly, the main issue is fixing the semantics early or late.  As I evolved Marpa, I decided it gave the most flexibility to fix the semantics as late as possible --
05:54 idiosyncrat it's obvious that this is an attractive idea, but it's a decision which I now believe was wrong.
05:55 idiosyncrat A disadvantage of late evaluation is that, when registration_init() is expensive, you'll pay the price every time you call Marpa::R2::Recognizer::reset_evaluation() even if your reset does not require most (or any) of the re-computaton.
05:58 idiosyncrat [ In Marpa::R3, I've decided that semantics are basically part of the grammar and in most cases, should be fixed at grammar creation time.  In particular this means that anything that can be precomputed with advantage at grammar time, should be precomputed at grammar time, and the app not allowed to modify it afterwards. ]
06:00 idiosyncrat I hope the above helps.
06:01 idiosyncrat When Marpa was first created, I left open the possibility of many unprecedented techniques.  Some of these, like Ruby Slippers, have proved to be very good ideas.
06:02 idiosyncrat Many others have received literally no use, but do clutter the codebase and some also impose runtime costs for certain apps, even though the app does not use that technique.
06:03 idiosyncrat The ability to totally redefine semantics as parse evaluation time is one of those unprecedented techniques which I now believe should have remained unprecedented. :-)
06:03 idiosyncrat s/as parse evaluation time/at parse evaluation time/
06:17 idiosyncrat amon: Btw this repeated re-registration issue is, I believe, one of the issues already fixed in R3.  Moving to R3 will, alas, expose you to many of the problems of dealing with alpha software, but I have kept the test suite working throughout, and have updated the docs as I went.  But I don't check the docs for global consistency as I go, so unfortunately documentation errors can be expected.
11:52 Cheery joined #marpa
15:12 amon_ joined #marpa
15:13 amon_ OK, I'm going to see whether Marpa::R3 will help. Alpha code is OK in this scenario.
15:13 amon_ First R3 impression: I like the improved event API very much :)
15:14 amon_ However, I have two questions regarding R3 (as per version 4.001_050):
15:14 amon_ Question 1: Stopping.
15:15 amon_ My grammar should only parse a document within a larger string, i.e. stop when trailing garbage is encountered.
15:15 amon_ Specifically: stop once no lexeme matches for the remaining input
15:16 amon_ With R2 I could set exhaustion/rejection to events, and `$recce->read()` would stop.
15:16 amon_ With R3, I get an error: “Character in input is not in alphabet of grammar: U+007d "}"” (I couldn't find the code throwing that error)
15:17 amon_ How can such an error be avoided?
15:17 amon_ My current workaround is to add a lexeme to the grammar that matches any input, but always rejecting it.
15:17 amon_ Top ::= ActualGrammar | NEVER ANY; NEVER ~ [^\s\S]; ANY ~ [\s\S]
15:18 amon_ Question 2: Ambiguity vs. Precedence.
15:18 amon_ R3 dies when the parse is ambiguous, which is extremely useful :)
15:19 amon_ I naively thought ambiguity would be resolved by using precedence alternatives, i.e. "||" vs. "|" operators.
15:19 amon_ But that only affects how recursive rules are rewritten, right?
15:19 amon_ Consider this code:
15:19 amon_ Marpa::R3::Scanless::G->new({ ranking_method=>'high_rule_only', source=>\q{E ::= KW || IDENT; KW~'if'; IDENT~[\w]+} })->parse(\"if")
15:20 amon_ That dies with an error: "Text is: if; There are 2 symches; Symch 0 is a rule: E ::= E; Symch 1 is a rule: E ::= IDENT"
15:20 amon_ Do I really need to explicitly and tediously "rank" every alternative in my grammar, even when using precedence?
15:21 amon_ (I don't want to use lexeme priorities because my real grammar has local ambiguities)
18:58 idiosyncrat joined #marpa
18:58 idiosyncrat amon_: re https://irclog.perlgeek.de/marpa/2017-12-14#i_15580353
18:59 idiosyncrat Yes, your case is an excellent example of the difference between precedence and rule rank.
19:00 idiosyncrat Jean-Damien had been after me to "auto-rank" alternatives in precedenced rules.  His requirement was to rank within precedence level, but auto-ranking would also solve your problem.
19:00 idiosyncrat An advantage of using R3 is that you get input into what goes in when. :)
19:01 idiosyncrat I'll look at the other 2 issues in a bit.
19:01 idiosyncrat Note: bug fixes take priority over new development in R3, even though it is alpha.
19:03 amon_ I'll probably discover quite a few bugs during the next few days (yayy testing :) I hope that's not too annoying.
19:03 amon_ None of those bugs will be urgent – please don't get distracted from more important long-term work.
19:03 amon_ But thank you very much for your comments
19:37 amon_ left #marpa
21:48 ronsavage joined #marpa
23:31 idiosyncrat joined #marpa
23:31 idiosyncrat amon: re https://irclog.perlgeek.de/marpa/2017-12-14#i_15581031 -- thanks!
23:32 idiosyncrat I do like to focus on user's because 1) that is ultimately what it is all about, and some open-source projects have forgotten that.
23:33 idiosyncrat 2.) Having users as I develop is *a good thing* -- I get testing and feedback about design, saving a lot of grief down the road.  And it's easier to attract users if they find the features they want, than if they don't. :-)
23:35 idiosyncrat amon_: re Question 1: https://irclog.perlgeek.de/marpa/2017-12-14#i_15580319
23:36 idiosyncrat Did you notice that you can also get the parser to stop using the R3's new event API?
23:38 idiosyncrat If you return the string 'pause' from the event handler, the recognizer will pause, just as it did in R2.  See http://search.cpan.org/~jkegl/Marpa-R3-4.001_047/pod/Event.pod#Event_handlers

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