Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-04-29

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

All times shown according to UTC.

Time Nick Message
00:53 ceridwen joined #marpa
01:39 jeffreykegler Btw, my question re Haskell the other day is not snark at the language -- being the lingua franca of theoreticians is no small accomplishment.
01:40 jeffreykegler It's just that in focusing my efforts, I take into account the likely audience, and the likely effect.
01:41 jeffreykegler In the particular case of parsing theory, Joop Leo's experience -- a spectacular result going unnoticed for a couple of decades ...
01:41 jeffreykegler and perhaps longer if I hadn't taken it up ...
01:42 jeffreykegler made me realize that if I expected to be noticed, I would have to target practitioners.
01:45 jeffreykegler So, with the new algorithm, I've done what's necessary for the theoretical community, but no more,
01:45 jeffreykegler while I have not stinted in my efforts to make Marpa a practical tool, and get it into the hands of folks who would use it.
03:22 ceridwen jeffreykegler, Mind if I ask some questions about the design of Marpa?
03:23 jeffreykegler I'd be glad to answer
03:28 ceridwen Can libmarpa handle binary data?  Is Marpa connected to libmarpa through the Perl C API?  What exactly is Kollos from an overarching perspective, and how does it relate to the previous two?  My motivation: Python needs a parsing library that doesn't suck, and I'm exploring options for how to get that.  My original plan involved writing my own, which I may still need to do for reasons, but Marpa seems like an interesting alternative.
03:31 idiosyncrat joined #marpa
03:31 idiosyncrat Answering the last question first, best way to port to Python if learn the Marpa::R2 API, if you have not already.
03:32 idiosyncrat And then look at the Libmarpa API -- the interface to the C core.
03:32 idiosyncrat To get all the Marpa::R2 features, you'd have to duplicate a lot of what is done in Perl/XS, which will be hard.
03:35 ceridwen That's kind of what I figured.
03:39 idiosyncrat There are others working on ports of Marpa, they may have comments on their experience.
03:39 idiosyncrat Back to first question: Should be no problem with binary data, actual input is done at the Perl level.
03:39 idiosyncrat Even the SLIF should be able to handle binary data OK.
03:39 idiosyncrat Second question: There is a core engine, at a very low level, written in C -- this is Libmarpa -- is is so low level there are symbols names, just integer IDs, for example.
03:39 idiosyncrat Libmarpa has a documented API, which is quite stable.  All actual use of Marpa goes through this API, so it really should be quite solid.
03:39 idiosyncrat Above the Libmarpa API is more C code, this time in Perl XS, and here's where symbols get names, etc., etc.
03:39 idiosyncrat And above that is Perl code.
03:39 idiosyncrat If I were doing a Python port, I use the Libmarpa API, and reinvent the upper layers.
03:41 idiosyncrat Kollos is the next version of Marpa, adding Lua to it as its language for semantics.
03:42 idiosyncrat Lua is very lightweight so it is reasonable to ask anyone using Marpa to also include a Lua interpreter.   It would not be reasonable to ask everyone using Marpa in their langauge to embed Perl.
03:43 ceridwen Yeah, it would be pretty much mandatory.  The main problem from my perspective would be building an interface to the C API that would be portable between CPython and PyPy (the two major Python interpreters, IMO).
03:43 idiosyncrat ceridwen: With Kollos, people who are interested in ports like you are would be able to include a library which has all the higher level stuff as well.
03:43 ceridwen Right.
03:44 idiosyncrat By the way, replies are coming to me after a weird delay, so if I am making even less sense than usual, that is why. :-)
03:45 idiosyncrat ceridwen: You might also look at the "thin" library in Marpa::R2.  This is, as the name suggests, a "thin" Perl wrapper of the Libmarpa API.
03:45 idiosyncrat If you decide to go ahead, your first cut at a Python-Marpa might be to try to duplicate this "thin" interface.
03:46 ceridwen I admire the work you've done with Marpa, it's one of the best examples of what I consider the new generation of parsers.  I am personally hoping to banish hand-written recursive-descent parsers from the world---really, a good modern parser should be part of every language's standard library.
03:47 ceridwen Duly noted.
03:48 koo8 joined #marpa
03:50 jeffreykegler joined #marpa
03:54 idiosyncrat It is kind of useable -- there's an example in the docs.  But none of the bells-and-whistles of Marpa::R2.
03:54 idiosyncrat Finally, when and if you try to duplicate the layers of Marpa::R2 above the Libmarpa API ...
03:54 idiosyncrat the Kollos project is a collaboration, so far mainly involving rns and I
03:54 idiosyncrat and the collaboration has me documenting much of what goes up in the upper Marpa::R2 layers.
03:54 idiosyncrat For example, I just wrote pseudo-code describing how I rewrite precedenced rules into BNF rules for Libmarpa.
03:54 idiosyncrat ceridwen: I hope this has answered your questions.
03:54 idiosyncrat ceridwen: Thanks!  And feel free to come back with more questions.  I backlog a lot.
03:56 ceridwen Yes, you answered my questions quite well.
04:01 ceridwen Thanks :).
05:17 idiosyncrat left #marpa
06:37 ronsavage joined #marpa
06:47 ronsavage Sigh. Finally got Apache working. Still no wiki, so back to ethernet.
06:50 ronsavage Agghhh. 'wiki' => 'wifi'.
12:44 hobbs joined #marpa
13:42 rns joined #marpa
13:52 rns ceridwen: re http://irclog.perlgeek.de/marpa/2015-04-29#i_10521340 -- this quick and dirty python binding [1] might be useful as a start. It is based on koo5's work that uses cffi [2] which "Attempt to support both PyPy and CPython."
13:52 rns [1] https://github.com/rns/libmarpa-bindings/tree/master/python
13:52 rns [2] https://cffi.readthedocs.org/en/latest/
13:56 ilbot3 joined #marpa
13:56 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
14:21 rns jeffreykegler: I was reading about lua macros the other day; they are implemented using LPeg [1] which "defines patterns as first-class objects" -- do we need/can we use smth. like that for LUIF?
14:21 rns One possible benefit of such approach is easy, out-of-the-box, extensibility -- e.g. [3] takes LPeg and adds AST building, error reporting, and some syntax sugar.
14:21 rns There is also that leg (LPeg-based Lua parser) thing [3] which looks (didn't tried it yet) similar to metalua (which proved to be not up to the task) in terms of extending the Lua grammar.
14:21 rns [1] http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
14:21 rns [2] http://siffiejoe.github.io/lua-luaepnf/
14:21 rns [3] http://leg.luaforge.net/grammar.html#section_Completing
14:27 hobbs joined #marpa
15:02 koo8 joined #marpa
15:03 koo6 joined #marpa
15:22 hobbs joined #marpa
15:29 lwa joined #marpa
16:15 jeffreykegler joined #marpa
16:17 jeffreykegler rns: re http://irclog.perlgeek.de/marpa/2015-04-29#i_10523468 -- Eventually, Kollos's LUIF should be self-parsing.
16:19 jeffreykegler In the meantime, we can use Marpa::R2.  This tool will be permanently useful, because the circular dependency of Kollos on LUIF and LUIF and Kollos may be a problem in some debugging situations, and a Perl based LUIF-to-KIR parser would bypass the circular dependency.
16:20 jeffreykegler I really would not like to see us spend time wrestling with PEG, or any top-down parser.
16:25 jeffreykegler Rather than get into a PEG project, we just write in a pure Lua ( https://github.com/rns/kollos-luif-doc/blob/master/etc/internals.md#the-pure-lua-file ) format, then add the LUIF on top later.
16:39 rns All valid points -- my thought were more about syntax -- in addition to BNF statements, e.g.
16:39 rns x ::= s a b
16:39 rns allow building LUIF grammars with expressions like
16:39 rns x = luif.R{ luif.LHS('s'), luif.S('a'), luif.S('b') }
16:39 rns or
16:39 rns R = luif.R, S = luif.S
16:39 rns x = R{ LHS('s'), S('a'), S('b') }
16:39 rns KHIL will need such an interface anyway (like luif_self:rule_parse(), etc.), so perhaps we allow applications to use it directly.
16:40 jeffreykegler A "direct to Lua" interface?
16:42 jeffreykegler Although I think R = { LHS = s, S = {'a', 'b'}} is more Lua-ish
16:42 rns Exactly! Not parsing the LUIF source, just calling KHIL method directly. This method for grammar building can have merits -- as Jerusalimchy say in second paragraph of http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
16:43 jeffreykegler Right, that's what I was trying to express in my "internals" document
16:44 jeffreykegler Oh, I see -- your proposed syntax follows LPEG.
16:44 rns Yes, just the set of methods which would build the external grammar for KIR.
16:45 jeffreykegler I think you understand why I really, really don't want to get into writing and maintaining a PEG parser
16:46 rns Sure -- me too. This would also add a disputable dependency, even if a Lua one. :)
16:46 jeffreykegler To be sure, Lua itself is parsed with recursive descent, but that parsing comes ready-made and trouble-free, and will require zero effort on our part.
16:48 jeffreykegler Do you want to write up a "direct to Lua" interface for me to review?
16:50 rns My thought exactly, if you don't mind.
16:50 jeffreykegler My problem with stuff like "x = R{ LHS('s'), S('a'), S('b') }" is that it looks less efficient than the more tabular form.
16:50 jeffreykegler But I did not read Roberto's article closely enough, so maybe something I am missing.
16:51 rns Well, LPeg is even more clumsy --
16:51 rns S = "a" * lpeg.V"B" + "b" * lpeg.V"A" + "" for
16:51 rns S <- 'a' B / 'b' A / ''
16:51 jeffreykegler Don't want to go there :-)
16:51 rns S ::= 'a' B | 'b' A | in BNF
16:52 jeffreykegler OK, great then.  Write it up.
16:53 jeffreykegler Refer to the sections of the Roberto article that you are working from.\
16:53 jeffreykegler ... don't assume I'm familiar enough with the article to recognize any resemblance.
16:55 rns Sure. It's mainly his "first-class patterns" idea that gets borrowed, not its implementation, though :). I'll keep you informed.
16:56 rns BTW, I filed some issues against kollos-luif-doc -- some perhaps premature, just as a braindump -- It'd be good if you take a look you when you have time.
16:57 jeffreykegler Github must be slow with the emails today.  I've been making comments on them, the most recent a few seconds ago.
16:57 rns Oh, I see you're doing just now, great.
16:57 rns I've just got the emails.
16:58 jeffreykegler Btw, in reading your D2L (direct to Lua) write-up, I'll have to deal with the fact that I am allergic to any suggestion of PEG.
16:59 jeffreykegler But I'll take anti-histamines or something. :-)
17:01 rns :)) Do we need to call it Direct (No PEG involved) to Lua? :)
17:01 rns DNPI2L :)
17:02 jeffreykegler I think it may be best I work on my own hangups without inflicting long acronyms on everyone  ...
17:02 jeffreykegler at least for now. :-)
17:03 rns So be it. :)) Time for me to go AFK, have a good day.
17:04 rns left #marpa
17:15 jeffreykegler rns: Actually, lifting Roberto's interface may be a pretty good idea.
17:15 jeffreykegler And it does seem reasonable to suppose that it is Lua-ish enough. :-)
17:47 hobbs joined #marpa
18:09 jeffreykegler joined #marpa
20:25 koo8 joined #marpa
20:26 koo6 joined #marpa
22:34 hobbs joined #marpa
22:37 ronsavage joined #marpa

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