Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2016-06-05

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

All times shown according to UTC.

Time Nick Message
01:32 ronsavage joined #marpa
01:39 idiosyncrat_ joined #marpa
01:46 idiosyncrat_ At this point, it's looking like I may be able to do both Lua and Perl semantics in Marpa::R3.
01:48 ilbot3 joined #marpa
01: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
03:40 ronsavage joined #marpa
04:39 idiosyncrat_ Good night!
04:54 rgrinberg joined #marpa
06:29 kaare_ joined #marpa
06:38 kaare_ joined #marpa
06:53 kaare_ joined #marpa
09:48 jdurand joined #marpa
09:50 jdurand Jeffrey, when testing against libmarpa, I came to the conclusion that the correct design when dealing with generic stacks is to have to notions of them: an input stack, that can be reused on demand, and an output stack, in which the different parse tree values can be pushed.
09:51 jdurand The subtility is the MARPA_STEP_RULE value step always get and set to this "output stack", the MARPA_STEP_TOKEN value step always get from the "input stack" and set to the "output stack", while the MARPA_STEPNULLING_SYMBOL always set to the "output stack"
09:52 jdurand Voilà, this is was just to inform and eventually ask if I do a serious mistake by doing these explicit stack distinctions
11:00 VsyachePuz joined #marpa
13:43 kaare_ joined #marpa
14:31 rgrinberg joined #marpa
16:58 idiosyncrat_ joined #marpa
16:58 idiosyncrat_ jdurand: re http://irclog.perlgeek.de/m​arpa/2016-06-05#i_12608518
16:59 idiosyncrat_ Yes, and this is how every implementation I've done has wound up working.
17:00 idiosyncrat_ Although input is typically not viewed as a stack, more as a random access array.
20:06 jdurand joined #marpa
20:08 jdurand Hello - in the Marpa::R2's SLIF there is as far as I remember a limitation on events, that can be set on prediction, completion or nulling, exclusively. The libmarpa doc does not expose this exclusion aspect - therefore I guess nothing prevent to set events of more than one type on a symbol is'nt it?
20:23 idiosyncrat_ jdurand: IIRC there's no limit.
20:23 idiosyncrat_ I've reached a milestone in the transition to Lua semantics.
20:24 idiosyncrat_ Marpa::R2 has a mini-VM, not Turing-complete, without about 2 operations, basically stack maniuplations.
20:25 idiosyncrat_ I'm not moving this over to Lua, operation by operation.
20:25 idiosyncrat_ I've just eliminated the first of the old operations, removing it from the code to make sure nothing is executing it.
20:26 idiosyncrat_ Typically this kind of transition is an accelerating process -- removing the 1st operation required putting in a lot of new Lua infrastructure,
20:27 idiosyncrat_ and less and less new infrastructure should be required as I proceed.
20:31 idiosyncrat_ jdurand: I just skimmed the docs and I don't see any such limits.
20:32 idiosyncrat_ Note that there are some things that might seem like limitations, depending on how you define that --
20:32 idiosyncrat_ you may wish to skim this section: http://search.cpan.org/~jkegl/Marpa-R​2-3.000000/pod/Event.pod#Implications
22:13 rgrinberg joined #marpa
23:02 ronsavage joined #marpa

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