Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-06-05

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

All times shown according to UTC.

Time Nick Message
00:01 idiosyncrat Ierusalismschy shows that asymmetric and symmetric coroutines have equivalent power -- one can efficiently simulate the other.  This, alas, does not carry over to my Perl-Lua implementation, however.
00:01 idiosyncrat Because Perl 5 does not have native coroutines, simulation of symmetric coroutines is not possible in my Perl-Lua implementation.
00:01 idiosyncrat This, however, is not an obstacle to any of the immediate goals for my new Perl-Lua coroutine mechanism, which are to use it for features now implemented in an event-driven fashion.  To replace event-driven code, asymmetric coroutines are completely sufficient.
00:28 idiosyncrat Comments welcome.
00:29 idiosyncrat Btw I spread my discussion over two days' backlog -- then end of yesterday and the beginning of today's.  I usually try to avoid this but today (yesterday?) I forgot.
02:04 ronsavage Callbacks means I can chop code which asks Marpa for a list of events and then determines various things based on the names of the events. Sounds good.
02:06 idiosyncrat ronsavage: Right.  And no more repeated invocation of resume() in a loop with the events -- just specify a list of handlers.
02:06 idiosyncrat IIRC just about every Perl module which deals with a similar problem-space uses handlers.
02:50 ronsavage Have you decided what parameters to pass to the callback. And will they be methods (have $self) or not?
02:51 idiosyncrat Don't seem like natural methods?  What would $self be?
02:53 idiosyncrat I'm thinking of emphasizing the use of closures, which means the parameters are just the basics specific to that event, and all the "object" stuff comes from the fact that the callback is a closure with access to variables visible in the context in which it was defined.
02:54 idiosyncrat Note that since Marpa::R3 remains alpha, what I decide in the next release *can* change -- if I come to realize it wasn't the best choice, in fact, it *will* change.
03:34 idiosyncrat ronsavage: re what object the event callbacks would be methods of -- most theoretically satisfying would be to say each event is an object and they are its methods.  But AFAICT that would be absolutely useless.
03:37 idiosyncrat Less useless is to say they are sort of impromptu methods of the recognizer object -- knowing what the recce is can be useful, but the theoretical status of these "methods" AFAICT is shaky, and the recce can be determined just as easily by defining the callback in a context where the recce is visible.
03:38 idiosyncrat This eliminates the need for any "special" arguments for $self, etc. -- these usually are not used.
04:02 ronsavage Just checking :-O) So they are just functions, unless there's an option for the user to supply a pre-created object, which in turn adds complexity and might make the code language-dependent. Scrap the object, which I vaguely remember you've mentioned re this new code.
06:19 ronsavage joined #marpa
06:50 idiosyncrat joined #marpa
08:02 sirdancealot joined #marpa
11:26 sirdancealot joined #marpa
11:44 sirdancealot joined #marpa
15:04 kaare_ joined #marpa
18:03 sirdancealot joined #marpa
19:37 idiosyncrat left #marpa
22:27 ronsavage joined #marpa
23:44 idiosyncrat joined #marpa

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