Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-30

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

All times shown according to UTC.

Time Nick Message
00:08 jeffreykegler joined #marpa
01:21 yxhuvud joined #marpa
02:29 jeffreykegler joined #marpa
02:30 jeffreykegler jdurand: I took a peek at http://irclog.perlgeek.de/marpa/2014-04-29#i_8654536 -- it's in keeping with my favorite way of resolving build issues --
02:30 jeffreykegler get someone else to figure it out :-)
02:37 jeffreykegler I just managed to figure out what's going on with the MY package.  ExtUtils::MakeMaker apparently defines this empty, as a convenience, which sounds like a great idea, but ...
02:39 jeffreykegler There's been an implicit assumption that the MY*|my* namespace was safe for the user to use, and a module just grabbing things out of it and running them ...
02:43 jeffreykegler Though perhaps the idea is that this only happens in a Makefile.PL, where it's reasonable for the Extutils::MakeMaker module to be a bit more heavy-handed that is usually wise.
02:44 jeffreykegler * "that is usually wise" -> "than is usually wise"
03:46 jdurand joined #marpa
03:46 jdurand Jeffrey, I have a difficulty to distinguish between events MARPA_EVENT_SYMBOL_EXPECTED and MARPA_EVENT_SYMBOL_PREDICTED
03:47 jdurand What is in practice the difference between them...?
03:58 jeffreykegler There is considerable overlap, but they use two different mechanisms
03:58 jeffreykegler MARPA_EVENT_SYMBOL_EXPECTED is part of the older "expected terminals" logic, and is only for terminals
03:59 jeffreykegler MARPA_EVENT_SYMBOL_PREDICTED comes from the newer general events logic, and is for any symbol, including terminals
04:00 jeffreykegler Reading my docs, they seem less than extraordinarily clear about this :-)
04:01 jdurand Ok, thanks. Does it mean that when MARPA_EVENT_SYMBOL_EXPECTED, then MARPA_EVENT_SYMBOL_PREDICTED is also set ? In other words can the application ignore MARPA_EVENT_SYMBOL_EXPECTED in favour of MARPA_EVENT_SYMBOL_PREDICTED?
04:02 jeffreykegler They are completely independent.  You'll get whichever you set, and both is you set both.
04:02 jeffreykegler * "is you set both" -> "if you set both"
04:02 jdurand Ok, that's clear - thanks
04:03 jeffreykegler That's my understanding at least.  The docs really should be clearer.
04:05 jdurand The neaming of MARPA_EVENT_NULLING_TERMINAL and MARPA_EVENT_SYMBOL_NULLED suggests better the distinction, and I suppose this is the same thing, where the later applies to all symbols including terminals
04:06 jdurand What about MARPA_EVENT_SYMBOL_COMPLETED: it applies to both by default ?
04:06 jdurand "The naming"
04:06 jeffreykegler MARPA_EVENT_SYMBOL_COMPLETED should apply to *all* symbols, yes.
04:07 jdurand Ok - many thanks
04:07 jeffreykegler This is one of the artifacts of my emphasis on backward compatibility.  As the interface expands, names that were clear because less clear.
04:09 jdurand Does the processing of MARPA_EVENT_SYMBOL_PREDICTED cost more than MARPA_EVENT_SYMBOL_EXPECTED ? I mean: suppose we know that a symbol is a terminal, then the application might want to favour the later.
04:10 jeffreykegler I'd suspect MARPA_EVENT_SYMBOL_EXPECTED is cheaper, because it's computed as a side effect and does not require special logic to be turned on, but ...
04:11 jeffreykegler I'd be suprised if the difference was measurable.
04:11 jdurand Ok, thnx
04:12 jeffreykegler Btw MARPA_EVENT_NULLING_TERMINAL is a grammar-definition-time event, not a recognizer event.
04:12 jeffreykegler Nulling terminals are errors.
04:13 jdurand Hmmm... ok -;
04:14 jeffreykegler That is, they are errors reportable at grammar definition time.  If you think about it, nulling terminals raise definitional issues ...
04:14 jeffreykegler how do you know when you see one?
04:15 jeffreykegler And Marpa, being an Earley's derivative, requires tricks to deal with nullables smoothly, ...
04:15 jeffreykegler so I just insist that all terminals always have length >= 1
04:16 jeffreykegler Users who need something to be both a terminal and nullable ...
04:16 jeffreykegler are free to define a "parent" symbol which derives two separate symbols, one a terminal and the other nullable.
04:17 jdurand Yep, I understand better the technical reason of this constraint
04:19 jdurand Things are clearer - have to leave - business work is profiling at the horizon! Have a nice night
04:19 jeffreykegler Bye
15:16 jeffreykegler joined #marpa
15:35 jeffreykegler Peter Stuifzand (who I've kept spying on) has me taking another look at C++: https://github.com/pstuifzand/marpa-cpp-rules
15:39 jeffreykegler Peter put a link to a series of apparently C++ - related lectures by Alex Stepanov and Paramjit Oberoi on his blog.  Peter's blog's links are broken at the moment, but here is the first on Youtube: https://www.youtube.com/watch?v=k-meLQaYP5Y
17:41 jdurand joined #marpa
17:42 jdurand Jeffrey, http://jeffreykegler.github.io/Marpa-web-site/libmarpa_api/latest/Registering-semantics.html#Registering-semantics says "404 Not Found" - same to you ?
17:47 LLamaRider joined #marpa
17:50 shadowpaste "jdurand" at 88.160.190.154 pasted "Marpa Abstract" (180 lines) at http://scsys.co.uk:8002/361910
17:50 jdurand I have been trying to design an C abstraction on top of Marpa - something that would resume the major steps of using it:
17:50 jdurand * grammar creation
17:50 jdurand * parsing
17:50 jdurand values
17:51 jdurand with bunches of callbacks for everything that is semantic
17:51 jdurand or user-space level
17:51 jdurand Any comment of any kind appreciated -;
17:53 jeffreykegler I'll take a look
17:54 jeffreykegler I've been thinking that the Libmarpa interface could be made a bit more cuddly.
17:54 jeffreykegler If the licensing is right, I'd just pull your code into Libmarpa.
17:55 jeffreykegler Re the Registering semantics page -- yes, there seems to be an issue there.
17:56 jdurand Re the abstraction: I wish to use it, a good way to validate it. Abstraction is missing progress and introspection, but I believe this is a no-op here - this is a priori needed only for expert usage, not for normal end-user application
17:58 jdurand I'll try to implement and use it - you see the goal is to avoir an #include "marpa.h", without hiding its power - just presenting a more cuddly interface as you say - not to say hiding "marpa.h" from the XSUB
17:59 jdurand I notice that with this interface, in theory, SLIF should just be a use case of it - the generic match callbacks ensures infinit levels of parsing - input is volontarirly left out of the abstract
17:59 jeffreykegler Once you've tried it out, we'll know more ...
17:59 jdurand voilà -; AFK for a while
18:00 jdurand Re tried out - sure -; I'll work on that - should not take long to implement
18:34 jeffreykegler jdurand: re http://irclog.perlgeek.de/marpa/2014-04-30#i_8658939 -- no problem -- it's just that the link moved when the document was rearranged -- http://jeffreykegler.github.io/Marpa-web-site/libmarpa_api/latest/Registering-semantics-in-the-valuator.html#Registering-semantics-in-the-valuator

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