Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-01-26

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

All times shown according to UTC.

Time Nick Message
00:13 ronsavage JK: I got a response re the symbol visibility:
00:13 ronsavage If you're starting a new project and it happens to be in ANSI C, any functions declared as "static" are only visible to that source file. I suspect that isn't applicable here, but since lua is small, maybe adding "static" declarations to the functions-to-hide will work.  Another possibility is to tread the functions to hide as a separate shared lib, and treat it as a plugin. Have the main library load the hidden one, and then expose whatever needs to be expo
00:19 ronsavage Adding truncated text .... 'and then expose whatever needs to be exposed. Not sure exactly how that would be implemented, or if it even makes sense. '
01:36 jdurand Though loading a plugin raises other problems, in particular this is not a thread-safe operation on all OSes
02:48 ilbot3 joined #marpa
02: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:49 idiosyncrat ronsavage: re https://irclog.perlgeek.de/​marpa/2017-01-26#i_13990250 -- thanks!
02:49 idiosyncrat Btw the "static" declaration is part of the "#include" side of the "#include" vs. link choice.
02:57 idiosyncrat Lua has built-into-it hooks for the "#include" method -- there's a one.c file and defines LUAI_FUNC, LUAI_DDEC, LUA_DDEF which can be set to "static" for just this purpose.
02:58 idiosyncrat === Marpa::R3 Changes ===
02:59 idiosyncrat I keep a list of these Changes in pod/Changes.pod btw, so you don't have to try to keep track of them by backlogging the IRC channel.
03:00 idiosyncrat The IRC channel version is likely to be more "chatty", with more informal explanations on my part, plus any comments by interested parties.
03:01 idiosyncrat Latest change is that a Perl named action (i.e., something like "action => My_Action::doit" ) must resolve to a Perl function.
03:02 idiosyncrat I expect many of you don't know this, but in Marpa::R2 it could resolve to a SCALAR, in which case the action always returned the scalar, so that resolution to say 42 ...
03:02 idiosyncrat was equivalent to resolving to the function
03:03 idiosyncrat sub My_Action::doit { return 42; }
03:03 idiosyncrat except the scalar could be more efficient.
03:04 idiosyncrat As of Marpa::R3, resolution to SCALAR is reserved for future purposes, and produces a fatal error.
03:04 idiosyncrat The "future purpose" is resolution to strings, which will be interpreted as Lua code.  This may never be documented in Marpa::R3, but it will become important in Kollos.
03:05 idiosyncrat === Forthcoming Marpa::R3 Changes ===
03:05 idiosyncrat I keep getting diverted to refactoring which really ought to be done first.
03:06 idiosyncrat The latest concerns when the semantics is settled.
03:06 idiosyncrat Right now the semantics is not settled until $recce->value() is called.
03:07 idiosyncrat This is because historically, that is, pre-SLIF, I thought it might be a good idea to users to change semantics in the recognizer.
03:08 idiosyncrat That way you could use a single grammar in multiple recognizers, each with a different semantics.
03:08 idiosyncrat Nobody ever made much use of this IIRC, not even me.
03:09 idiosyncrat And with the SLIF and DSL-driven Marpa, the semantics really is pretty much cast in concrete in the DSL, and therefore in the grammar.
03:10 idiosyncrat Marpa::R3 will move all semantics options from the recognizer back to the grammar ...
03:16 idiosyncrat This has several advantages.
03:17 idiosyncrat Right now there's the semantics are figured out in both the recognizer and the grammar, which makes the code complex.  Marpa::R3 will settle the semantics once and for all in the grammar.
03:19 idiosyncrat 2nd advantage: Right now the need to defer finally settling the semantics until value() is called makes it hard to add new features.
03:20 idiosyncrat I'm moving this particular refactoring to the head of the queue because I realized that I was about to change this semantics logic, and I don't want to change it to just have to redo it.
03:23 idiosyncrat http://matrix.cpantesters.o​rg/?dist=Marpa-R3+4.001_033
03:23 jdurand This seem a good idea in the sense that getting semantics in perl had a true cost in the value() phase
03:23 idiosyncrat Marpa::R3 is 100% OK on CPANtesters, as above, but that may be because Andreas's tests have not yet hit.
03:24 idiosyncrat jdurand: Oh yes!  Advantage #3: more efficient.
03:26 idiosyncrat The CPANtesters folks often do mysterious cleanups of the test results, eliminating spurious FAILs from the long-term records.
03:27 idiosyncrat Or it could be that Andreas's usual 6 or so FAILs have yet to hit.
03:38 ronsavage joined #marpa
11:41 VsyachePuz joined #marpa
21:44 ronsavage joined #marpa
22:23 kaare__ joined #marpa
22:34 kaare__ joined #marpa

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