Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-07-03

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

All times shown according to UTC.

Time Nick Message
02:14 idiosyncrat I've changed Marpa::R3 so that a return of 'ok' from an event of type 'before lexeme' is a fatal error.
02:16 idiosyncrat The problem in the FAQ, as I see it, derives from trying to use a default event handler for a 'before lexeme' event.  Pre-lexeme events are special in the way they handle location.
02:17 idiosyncrat All other events leave you at the location where they trigger.  Pre-lexeme events move you backward, and that means it's hard to write common logic for them and other events.
02:43 ronsavage JK: But the question remains: With pause before, then when the handler returns, why doesn't Marpa just keep parsing, and thereby move past the lexeme which trigger the callback?
02:47 ronsavage Re the FAQ: Do you think I should reword it? I could say not that pause before should be abandoned, but that it should and indeed must be combined with the handler returning 'pause'.
05:25 kaare_ joined #marpa
06:07 ronsavage joined #marpa
07:10 ronsavage joined #marpa
18:16 idiosyncrat ronsavage: re https://irclog.perlgeek.de/marpa/2017-07-03#i_14817394
18:17 idiosyncrat I'd hate to see pre-lexeme events abandoned -- they're unique in allowing a kind of lookahead with Marpa.
18:17 idiosyncrat But this discussion has me re-thinking the matter.  Perhaps there's a more intuitive way of packaging the facility?
18:19 idiosyncrat Is anybody listening who uses pre-lexeme events?
18:19 idiosyncrat jdurand, rns: ??
18:20 idiosyncrat Note that Marpa::R2 is not going to change -- we're only talking about Kollos/Marpa::R3
18:20 idiosyncrat One possibility is to eliminate pre-lexeme events per so, but keep post-lexeme events and
18:21 idiosyncrat 1) Add a "skip" option, so that the lexeme is skipped over; and
18:22 idiosyncrat 2) allow the app to change position in the input block, so that it can move its current position to the start of the lexeme.
18:23 idiosyncrat This accomplishes what pre-lexeme events, do, at the expense of a bit more trouble on the part of the app writer, but it may be a clearer way to package the feature.
19:47 idiosyncrat left #marpa
21:05 ceridwen joined #marpa
23:19 idiosyncrat joined #marpa
23:25 ronsavage joined #marpa
23:41 ronsavage JK: Or, in the case of pre-lexeme events (which I like), could you make it mandatory for event handlers to call lexeme_read() to get past the lexeme, or to move the resume position to after the lexeme? That was the app could actually move as far forward (or back!) as they wish?
23:44 idiosyncrat The problem is that lexeme_read() can easily trigger its own events, so that calling lexeme_read() inside an event handler could mean calling an event handler inside an event handler.  Currently I make that a fatal error, because it's like to result in tears.
23:44 ronsavage Elsewhere, in Event.pod, just under the heading 'Post-lexeme events', you have :lexeme ~ <a> pause => after event => '"a"'. I started using those nested quotes. Then I chopped the inner ones, and then I chopped the outer one too! And the tests worked in each case. I'd really like to see the docs point out that the quotes are redundant, unless of course the name contains special chars.
23:44 ronsavage OK: Forget my comment on lexeme_read()!
23:45 idiosyncrat I think this business with pre-lexeme events is not one I will resolve in a hurry.
23:45 ronsavage Yeah....
23:46 idiosyncrat I want to bring in some of the others who've used Marpa::R2 a lot, and get their opinions.
23:46 ronsavage Understood.
23:46 idiosyncrat Btw, if I do add a "skip" option to pre-lexeme events, that makes them very like "discard" events, which means several different ways to do the same thing.
23:47 idiosyncrat My thought is to leave pre-lexeme events (more or less) as they are in Marpa::R3, and move on to the changes in symbol and rule accessors.
23:48 idiosyncrat Recall I'll need to divide symbols in Marpa::R3 into external (which is what an app writer will almost always use) and internal.
23:48 idiosyncrat That's because I'll be doing a lot more grammar rewriting and external (= user's point of view) will be pre-rewrite ...
23:49 idiosyncrat and internal will be post-rewrite.
23:50 idiosyncrat So now I'm doing a kind of mitosis on grammar accessors, where they divide into two groups.
23:51 idiosyncrat In my revision, I'm hoping a lot of the changes will be invisible to your apps, in that the old accessors will access the external symbols/rules and as long as everything is consistent, no difference will be noticed.
23:51 ronsavage OK. So leave them working as is, even if with some limitation, knowing they may well need revisiting after the major part of this whole re-write is nearing completion.
23:52 idiosyncrat But I'm also taking advantage of the opportunity to revisit names of methods, so they'll also be some (hopefully rote) renamings required.
23:52 idiosyncrat ronsavage: I'll want, if you're willing, your input on the names.
23:53 idiosyncrat For after the symbol/rule mitosis, by current plan is to tackle another interface issue, with values and parse series.
23:54 idiosyncrat I'm tackling all the IF issues at once at this point, with the idea of incurring all the pain at once, and putting the more visible kind of backward incompatibility behind us as much as possible.
23:55 ronsavage Glad to help with the naming.
23:56 idiosyncrat Recall that in Marpa::R2 right now, $recce->value() is a recce method, and there are parse series and a $recce->series_restart() method.
23:57 idiosyncrat It's because clear to me that the valuer is an class like the grammar and recognizer, one that got buried in recognizer methods.
23:58 idiosyncrat So I plan to create an new SLIF "valuer" class, with a constructor, and a iterator, etc.
23:59 idiosyncrat $recce->series_restart() will become a new call to $valuer->new(), eliminating a lot of "state" logic inside the recognizer.
23:59 idiosyncrat Low-level, getting a value will be something like:

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