Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-03-06

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

All times shown according to UTC.

Time Nick Message
01:07 flaviu joined #marpa
02:30 jeffreykegler joined #marpa
02:31 jeffreykegler Indirectly, by the way, my PEG post also addresses the composability of Perl 6 subgrammars.
02:32 jeffreykegler Perl 6 grammars and PEG share in common that they are formalisms of top-down parsing.
02:33 jeffreykegler PEG syntax is simpler, but more restrictive -- even so its grammars are not composable in general.
02:34 jeffreykegler With Perl 6 grammars, even more behaviors are allowed, so you know (in general) less about the grammar, and it is therefore less likely to compose.
02:35 jeffreykegler Marpa grammars compose, if their lexing and event discipline is compatible.
02:49 Aria Yup.
02:49 Aria That's what excites me most about Marpa.
05:23 ronsavage joined #marpa
13:10 lwa joined #marpa
14:26 rns joined #marpa
16:24 jeffreykegler joined #marpa
16:38 rns jeffreykegler: I tried to get the end of token using marpa_r_earley_set_value() instead of re-scanning input --https://github.com/jeffreykegler/libmarpa/com​mit/24be78999346c780e87d5189d8c0da064e96a5ce -- and noticed that this made a tiny bit slower, even on longer json string and numbers.
16:39 rns I see marpa_r_earley_set_value() and marpa_r_earley_set_values() use r_update_earley_sets (r) -- which is said to be "called exactly once during a normal parse at the end, when it is time for a bocage to be created" and affect time complexity? Is it used in the said accessors by design?
16:48 jeffreykegler rns: re http://irclog.perlgeek.de/m​arpa/2015-03-06#i_10235079
16:48 rns I tried to remove r_update_earley_sets (r) and the resulting code passes all tests in libmarpa (incl. json) and Marpa::R2 (including sl_discard*.t) in my setup.
16:49 jeffreykegler When accessing via an arbitrary Earley set, an array is used.
16:49 jeffreykegler This array is *not* kept dynamically up to date as the parse progresses.
16:50 jeffreykegler It is, for efficiency, intended to be created at the end.
16:50 jeffreykegler But "special" accessors, trace functions, etc., also do build that array.
16:50 jeffreykegler Because their usage is not considered "normal"
16:52 rns Ok, I see. I have to say, the difference with and without r_update_earley_sets (r) for json.c is negligible.
16:54 rns I as just puzzled that rescanning the input to find ends of string and numbers turned out to be faster than accessing some data structure and error checking. Perhaps it can be reversed on a lot of longer string/numbers -- what do you think?
16:54 rns s/I as/I was/
16:56 jeffreykegler Elminating the call to r_update_earley_sets (r) seems risky to me -- the code goes up to use the data structure it is updating.
16:58 rns Now, I agree -- as I said, removing it doesn't make a difference.
17:01 rns Overall, does a patch like that (http://irclog.perlgeek.de/m​arpa/2015-03-06#i_10235079) make sense? Is that proper use of Earley set value(s) setterg/getters?
17:04 jeffreykegler Doing that for every Earley set as you progress, which I think is what is happening ...
17:04 jeffreykegler is something to be avoided.
17:07 jeffreykegler Yes, looking at it.
17:07 jeffreykegler You want to use your own data structure for that.
17:08 jeffreykegler In the future, btw, I plan to remove the Earley set values, on the idea that it is really something that should be done in the layers above Libmarpa.
17:09 jeffreykegler It's there now because when doing it via Perl, my choice was adding an int to the Earley sets, or creating another large Parl array, and there the efficiency tradeoffs seemed pretty obvious.
17:12 jeffreykegler A "usage note"in the Libmarpa doc about this might be a good idea.
17:13 rns Ok, got that. And yes, removing Earley set values and leaving values for marpa_r_alternative() only and saying that they can be used to access a data structure looks like a good idea now that I tried both. :)
17:20 rns Another topic: in character-per-earleme model, is Earleme = Earley set = (or has one-to-one correspondence with) Location in the input?
17:20 jeffreykegler There can be Earlemes without an Earley set.
17:21 jeffreykegler Imagine, for example, a character-per-earleme model in a standard language with comments.
17:21 jeffreykegler You don't want the overhead of an Earley set for all those earleme locations in the middle of a comment.
17:22 rns Yes.
17:24 rns Earlemes without an Earley set == empty earlemes?
17:24 jeffreykegler Yes -- Earlemes with no Earley items.
17:25 jeffreykegler Again, think about a comments, and all the earlemes inside it.
17:25 jeffreykegler Nothing starts or stops at those earlemes, so there are no Earley items, and therefore no need for the empty Earley set.
17:29 rns Yes, but creating empty earlemes is up to the application's decision -- to call marpa_r_earleme_complete() without marpa_r_alternative() or not to call it so?
17:30 jeffreykegler IIRC yes.
17:31 jeffreykegler Early on, I did a lot of experiments with the Earleme per character model, but I was very naive about the interest out there for fancy extensions to Earley's algorithm.
17:32 jeffreykegler Right now, the one-Earleme-per-token model, where earleme location is the same of location in terms of Earley sets.
17:32 jeffreykegler is the one that gets all the interest.
17:33 rns Yes, looks like that.
17:33 rns My thought was that character-per-earleme model would automatically ensure composability of all grammars that use it.
17:33 rns Sans events, of course.
17:33 jeffreykegler One of my thoughts, also, yes.
17:36 rns So, perhaps a lightweight implementation of pure BNF (literals/symbols) directly on top of libmarpa would also be fast enough and composable by design at the same time.
17:36 rns So any other syntax (EBNF, etc.) can be implemented on top of it.
17:37 rns By "compiling" to it (rewriting ).
17:39 jeffreykegler Hmmm.  Interesting.
17:43 rns Add to it a valuator which exposes parse results as Marpa_Grammar with suitable methods and pure-Marpa BNF parser directly on top of libmarpa is here.
17:44 rns Don't know will it be "efficient enough" though.
17:46 rns Sorry, have to go, will baclklog. AFK.
17:46 rns left #marpa
17:55 sirdancealot joined #marpa
18:30 Aria So far, I've done an earley set per character model in lotsawa.
18:30 Aria Though being precise enough with memory for that to be efficient is V. Hard in javascript.
18:31 Aria (doable, I think, but will require a lot of care.)
20:27 koo7 joined #marpa
21:55 idiosyncrat joined #marpa
21:55 idiosyncrat http://www.bloomberg.com/news/article​s/2015-03-06/want-a-job-in-silicon-va​lley-after-yale-good-luck-with-that
21:56 idiosyncrat Maybe Marpa will help put Yale back on the map. :-)
22:11 ronsavage From that article: "Yale's computer science department has focused more on theory than practical applications". Well, the theory behind Marpa should be right up their alley :-)
22:14 ronsavage Perhaps they should hire a certain 'Professor' Kegler!
22:17 idiosyncrat Actually, my last academic rank was full-time Lecturer (in Yale's Med School).  So I am "almost" a Yale professor.
22:19 idiosyncrat It was as a Grad student at Yale that I learned parsing -- my professors were Alan Perlis and Ned Irons.
23:48 ronsavage joined #marpa

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