Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-04-15

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

All times shown according to UTC.

Time Nick Message
00:10 jeffreykegler joined #marpa
06:35 rns joined #marpa
06:36 ronsavage joined #marpa
07:10 rns ./me catching up with recent developments on the kollos repo and the backlog
07:10 * rns catching up with recent developments on the kollos repo and the backlog
11:57 rns jeffreykegler: Great to see your recent work on kollos.
11:57 rns re http://irclog.perlgeek.de/m​arpa/2015-04-14#i_10436542 -- IIRC, the LUIF's design was started in [1] with JSON grammar as an example in [2] and grammar for LUIF stat in [3] -- I take it we can start from/use them in the current developments?
11:58 rns The first thing that comes to mind is borrowing literals and character classes and comments from SLIF.
11:58 rns [1] https://github.com/jeffreykegler/koll​os/blob/master/notes/design/notes.md
11:58 rns [2] https://github.com/jeffreykegler/ko​llos/blob/master/working/json.luif
11:58 rns [3] https://github.com/rns/MarpaX-Languages-Lua-AST/​blob/master/lib/MarpaX/Languages/Lua/LUIF.pm#L22
12:15 rns jeffreykegler: The three layers of processing described in http://irclog.perlgeek.de/m​arpa/2015-04-14#i_10436943 look like a nice structure for docs/code in LUIF -> KHIL -> KIR -> KLOL -> Libmarpa pipeline for grammar rewriting.
12:15 rns Perhaps we can use a quick-and-dirty Libmarpa binding to luajit like [1] (it has a basic lexer which can use either Lua patterns or regexes (via a lua wrapper for PCRE library)).
12:15 rns [1] https://github.com/rns/libma​rpa-bindings/tree/master/lua
12:15 rns jeffreykegler: A question about strand parsing (which I'm much interested in) -- is it intended as an extension to Libmarpa written in Lua or a part of Libmarpa itself?
12:19 lwa joined #marpa
13:07 rns left #marpa
16:58 jeffreykegler joined #marpa
17:00 jeffreykegler re http://irclog.perlgeek.de/m​arpa/2015-04-15#i_10444248: yes, and something I'd like volunteers to take on (rns, jdurand, Aria, others?) is to create a LUIF reference document.
17:00 jeffreykegler That should be the next step, I think, toward Kollos's higher layer.
17:01 jeffreykegler Level of detail like the Lua 5.1 reference, but it would be shorter.  In particular, while the LUIF includes all of Lua 5.1, it need not repeat the Lua docs, just refer to them.
17:02 jeffreykegler rns: re http://irclog.perlgeek.de/m​arpa/2015-04-15#i_10444364 -- yes, this is my plan exactly.
17:03 jeffreykegler re http://irclog.perlgeek.de/m​arpa/2015-04-15#i_10444365 -- I think this would be a separate effort -- my plans for the lower layer don't allow for a "thin" interface.
17:04 jeffreykegler That is, I had thought that a thin Lua wrapper layer over the Libmarpa calls would be part of roadmap, but as it turns out, the approach I am taking is not consistent with it.
17:05 jeffreykegler Not that a thin Lua/LuaJIT wrapper over Libmarpa would not be nice to have, but it's just not going to be a direct by-product of my Kollos work, alas.
17:07 jeffreykegler When Kollos is done, Lua will be an integral part of the interface -- it won't be like Libmarpa and Perl, where this is a thin Perl layer, more or less direct to the Libmarpa calls.  (I note this is *not* much used, however.)
17:08 jeffreykegler Within Kollos, Libmarpa would evolve to a smaller, more efficient engine with a simpler interface, but one which, unlike the current Libmarpa interface, you would not use directly -- for practical, non-internals work, you'd always use it via Kollos/Lua.
17:10 jeffreykegler rns: re http://irclog.perlgeek.de/m​arpa/2015-04-15#i_10444367 -- strand parsing will become an integral part of Kollos/Lua, sometimes even invisiible to the user.  However, even starting on strand parsing is some months off.
17:12 jeffreykegler Back to the issue of no thin interface inside Kollos.  Lua is very small, perhaps even smaller than my current mini-virtual machine and semantics code, so making it an inseparable part of the interface imposes little or no burden on the user.
17:13 jeffreykegler It's very different from a case where, in order to use Libmarpa, you much also use Perl 5.  That's why a "thin" interface in Perl makes more sense than one in Kollos.
17:13 jeffreykegler Again, though, I note Marpa::R2's thin interface gets relatively little use, AFAICT.
17:35 koo7 joined #marpa
20:03 jeffreykegler For the KHIL (the Kollos upper layer) I have rewritten up how the rewrite of sequence rules into BNF rules should proceed: https://github.com/jeffreykegler/kollo​s/blob/master/notes/design/sequence.md
20:08 jeffreykegler By the way, while participation in the Kollos effort is open to everyone who finds their way here ...
20:09 jeffreykegler I am not advertizing it beyond this channel and perhaps the G+ group.
20:10 jeffreykegler That's on the idea that people you need some experience with Marpa to understand what makes sense in an interface language and what does not.
20:11 jeffreykegler Once we have a LUIF reference doc, we can release it to the wider world.
20:51 jeffreykegler Something I forgot to mention about the LUIF/KHIL (KHIL == "Kollos higher layer")
20:52 jeffreykegler It's prototype or first draft does *not* have to be in Lua.  To have a working Kollos, of course, the KHIL must be in Lua 5.1.
20:53 jeffreykegler But we can sidestep chicken-and-egg issues, initially, by having Marpa::R2 parse the LUIF and turn it into the KIR.
20:53 jeffreykegler KIR == "Kollos intermediate representation"
20:54 jeffreykegler The Perl version may prove long run useful as well.
20:55 jeffreykegler This choice (Perl vs. Lua and perhaps other options) I want to leave up to the team which starts work on the KHIL.
22:04 flaviu joined #marpa
22:35 ronsavage joined #marpa
23:34 sivoais_ joined #marpa
23:38 flaviu joined #marpa
23:52 aredridel joined #marpa

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