Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2016-03-30

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #marpa
01:48 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
02:12 teatime joined #marpa
03:57 jdurand idiosyncrat_: nice thoughts I agree this would be nice, in the sense that it would become a new development tree
03:59 idiosyncrat_ jdurand: a lot of your suggested features that I'd rejected because of backward compatibility ...
03:59 idiosyncrat_ could now be done.
03:59 idiosyncrat_ Things like ranking SLIF rules in order of appearance in the precedenced statement.
04:00 jdurand Yes, I understood
04:00 jdurand Also I had to write several times wrappers on top of it, wonder if it should come in or not
04:01 idiosyncrat_ Hopefully you might be able to find some time to help with Marpa::R3.
04:01 idiosyncrat_ Pull requests, etc.
04:02 jdurand I am thinking dropping the bail if favor of the croak, using a logging provider, making it a role, use Class::XSAccessor, making it one package == one pm file etc
04:04 idiosyncrat_ We can do a bunch of stuff, one feature at a time.
04:05 idiosyncrat_ A related question.
04:05 jdurand Sure
04:05 jdurand extending the "parse" method of current grammar package: I believe it would be more attractive if userspace can be writen a-la-event-driven-coding style
04:05 idiosyncrat_ To do throw objects properly, I'd have to require Perl 5.10.1
04:05 idiosyncrat_ s/throw/thrown/
04:06 jdurand yes, IMHO no pb to drop 5.10.0 - definitely
04:06 idiosyncrat_ An alternative is to drop back to 5.8, which would help some users, but I think that may be too hard at the XS level.
04:07 idiosyncrat_ And it would mean no cool object-handling in croak().
04:07 jdurand frankly I don't think perl community would bail (-;) for such decision
04:07 idiosyncrat_ jdurand: OK, so I think I can take it that you are enthused about the Marpa::R3 idea.
04:08 idiosyncrat_ "bail"?
04:08 jdurand a joke, reference to Marpa::R2 bail v.s. croak
04:09 jdurand Ok, maybe the best would be to write down an up-to-date document about all the ideas - it is currently a bit too much spreaded between mails, the google group, bug and pull requests
04:10 idiosyncrat_ jdurand: Actually my plan is first to create the github repo, and do some initial hacks myself.
04:10 idiosyncrat_ Specifically, eliminate the PSIF (Peter Stuifzand's interface, now not used) ...
04:11 idiosyncrat_ and the NAIF.
04:11 idiosyncrat_ Rename everything and get a clean build.
04:12 jdurand ok
04:12 idiosyncrat_ And then to do one feature at a time, asking for volunteers for specific features.
04:12 idiosyncrat_ At some point we may want to do a "design", simply to determine how far we are going to go.
04:13 jdurand do you mind about a rewrite and/or refactor of perl code
04:13 idiosyncrat_ Yes, a refactor would be very nice, but first we'll do some simple new features/ simplifications/ improvements.
04:14 jdurand Sure - one thing at a time otherwise this will be a failure
04:14 jdurand ok, then
04:14 idiosyncrat_ My idea here is that Kollos (which is still a plan) is very much "break everything and rebuild it" ...
04:15 idiosyncrat_ and this will be the opposite -- we do what we can do incrementally, bit by bit, and when that stops being possible, we stop.
04:16 idiosyncrat_ So a refactor, while tempting, we'd leave to last, and then try it and see how hard it is -- if it's too hard we stop.
04:17 idiosyncrat_ If a refactor succeeds, it might start a virtuous cycle -- more readable code means more maintainers, means better code and more features, and on and on ...
04:17 idiosyncrat_ But first focus on stuff we know that we *can* deliver on.
04:17 jdurand ok, understood
04:18 idiosyncrat_ That is, I *know* I can cut out the PSIF and the NAIF.
04:18 idiosyncrat_ I'm pretty sure your UTF8 fix can just be dropped it.
04:19 idiosyncrat_ And that the default for LATM and the default action can be changed.
04:19 idiosyncrat_ And just that stuff will make lots of folks happy.
04:19 jdurand Are there features that can go in the C library directly ? I was thinking to the automatic ranking - I do not remember if this is implemented at perl level or C level
04:19 idiosyncrat_ s/UTF8 fix can just be dropped it/UTF8 fix can just be dropped in/
04:20 idiosyncrat_ Either Perl or XS level, but not Libmarpa level.
04:20 jdurand ok
04:20 idiosyncrat_ I can figure that out when the time comes, I hope it won't be hard.
04:21 jdurand ideas/wanted features/fix should be writen down first, by everybody
04:22 jdurand I guess that one feature where libmarpa is a candidate is a generalized notion of exclusion in alternatives
04:22 idiosyncrat_ Huh?
04:22 jdurand i.e. A ::= B - C
04:22 jdurand A is successful if B matches but not C
04:22 jdurand s/but/and/
04:23 idiosyncrat_ Not context-free.
04:23 jdurand ah ok
04:23 jdurand tant pis then, will be suggested in userspace
04:23 idiosyncrat_ I don't think so, anyway -- it's easy in regular expressions, but harder than it seems in context free.
04:24 jdurand ok, nevermind - writing down things and you digest/agree/reject etc
04:25 idiosyncrat_ Yes, a list is probably good / necessary, but ...
04:26 idiosyncrat_ bear in mind that despite the name, I think of this as only a small incremental improvement over Marpa::R2,
04:26 idiosyncrat_ not a radically new version.
04:27 idiosyncrat_ I don't want to open the way to the kind of process that marked the beginning of Perl 6.
04:27 jdurand Yes, I realise that - this is ok, same code base but incremental improvements, at least reopening a dev-tree out of Marpa
04:27 idiosyncrat_ I *do* however, want to incorporate a number of the things you have wanted and that we could not do.
04:28 jdurand fine with me
04:28 idiosyncrat_ The new dev tree is mainly so I can keep Marpa::R2 ultra-stable for production users.
04:29 idiosyncrat_ So, yes, it's called Marpa::R3, but it's really still Marpa::R2 at heart. :-)
04:30 idiosyncrat_ OK, so your vote is a "Oui", ...
04:31 idiosyncrat_ I hope to hear from others.
04:31 jdurand Exactly, waiting for others reactions when they will backlog
04:31 jdurand My vote is a Oui -;
04:32 idiosyncrat_ I will backlog, but it is time for me to say ...
04:32 idiosyncrat_ Good night!
04:34 jdurand Thx - it is morning here lol - good night
06:31 ronsavage joined #marpa
06:31 ronsavage Back on line, sometimes :-(.
06:33 ronsavage I've quickly read the backlog. Will revisit. My internet connexion is flaky. R3 sounds good. Something nags at my mind as a potential fix. I'll try to document it.
06:49 koo7 joined #marpa
07:17 koo7 joined #marpa
08:01 pczarn joined #marpa
08:01 pczarn Exclusion is still possible with simple logic.
08:04 pczarn You create a rule `A ::= B | C` and a completion event for `A`. The event would only allow completions with a bocage node (A, i, j) if there is a node (B, i, j) and no node (C, i, j).
08:54 pczarn No, I put it wrong -- `B` and `C` can be predicted somewhere else. The event must have full information about the cause of every completion just before it is performed.
11:01 kaare_ joined #marpa
11:13 pczarn Actually, yes, it doesn't matter what else predicted `B` and `C` at `i`.
11:30 rns joined #marpa
11:34 rns re Marpa::R3 -- good idea, all the more so with to fix annoyances even if it breaks backward compatibility. I'd put a thing or two for discussion. :)
11:37 rns pczarn: Can A ::= B - C be implemented by allowing A::= B C *and* A::= B and eliminating all parse trees containing A::= B C by filtering the SPFF?
11:49 pczarn joined #marpa
11:50 pczarn I suggest writing `A ::= B & C` for intersection and `A ::= B & !C` for exclusion
11:52 pczarn rns: I'm not sure, if exclusion is handled during evaluation, the recognizer is unaware, and could report wrong parse errors and ambiguity that shouldn't be there
11:53 rns pczarn: re http://irclog.perlgeek.de/marpa/2016-03-30#i_12259124 -- isn't A ::= B & C the same as A ::= B C?
11:53 pczarn in the extreme case, it would report a successful parse with 0 parse trees
11:54 pczarn it's intersection and concatenation
11:54 rns ok
11:54 pczarn to be clear, in the former, we have (B, i, j) and (C, i, j)
11:54 pczarn in the latter, (B, i, j) and (C, j, k)
11:56 rns ok, you mean SPFF nodes, not grammar rules.
11:56 rns re http://irclog.perlgeek.de/marpa/2016-03-30#i_12259142 and http://irclog.perlgeek.de/marpa/2016-03-30#i_12259149 -- good point.
11:57 pczarn yes
11:57 pczarn intersection is similar to zero-width lookahead
11:58 rns yep, and exclusion to negative ZWA
11:59 rns zero-width negative look-ahead assertion, in Perl regex terms
12:03 rns FWIW, http://www.bramvandersanden.com/publications/sanden2014thesis.pdf describes SPFF filtering algorithms, some of them applicable while recognizing.
12:09 rns shorter version: http://www.bramvandersanden.com/presentations/sanden2014thesis.pdf
12:30 pczarn Interesting, could be useful, thanks
14:32 pczarn joined #marpa
14:39 koo7 joined #marpa
18:20 jdurand joined #marpa
18:20 ceridwen joined #marpa
18:22 jdurand Re http://irclog.perlgeek.de/marpa/2016-03-30#i_12258278 - I have no doubt it is easy - I have in mind another technique with sub-grammars in the general case - and of course it is more easier with character ranges if this is limited to what (if I recall well) EBNF states
19:06 koo7 joined #marpa
19:26 koo7 joined #marpa
19:58 koo7 joined #marpa
21:24 koo7 joined #marpa
22:51 idiosyncrat_ joined #marpa

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