Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-05-04

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

All times shown according to UTC.

Time Nick Message
01:54 hobbs joined #marpa
04:13 idiosyncrat joined #marpa
04:15 idiosyncrat latk had filed an issue on Marpa::R2 which is probably a code bug.
04:16 idiosyncrat The fix may require a backward-incompatiblity -- the current behavior seems to be counter-intuitive and contrary to the docs, but some folks may be relying on it.
04:17 idiosyncrat I may, therefore, move Marpa::R2 to a new major version #, 3.0, just to give folks who upgrade a heads-up
04:20 idiosyncrat On another topic, the topic of Marpa::R2 and OOP has been raised -- Marpa warns folks about trying to extend Marpa objects, and do other things to its namespace.
04:21 idiosyncrat I don't think cars warn people against trying to fix the engine while driving, but warning against the programming equivalent seems to be necessary.
04:22 idiosyncrat Marpa gets its semantics from names of Perl packages and names of methods, and expects to be able to assemble them in the standard way, and also to be able to search for constructors.
04:25 idiosyncrat Some OO packages are written on the assumption that only the symbols tables are theirs to hack.  Marpa::R2 expects the namespace of its actions to stay "standard".
04:26 idiosyncrat The other matter is inheriting Marpa objects, etc.
04:27 idiosyncrat I hate to speak out about this kind of stuff, as its proponents are not shy from accusing folks like Torvalds of ignorance when it criticizes it, and I like to try to accomplish stuff with my time,
04:27 idiosyncrat rather than engage in disputes like to accomplish nothing.
04:28 idiosyncrat s/like to/likely to/
04:29 idiosyncrat Module::Build is an example of a module which allowed and encouraged inheritance, and it quickly became unmaintainable.
04:30 idiosyncrat How do you maintain a module when you don't know what's going on in its namespace.
04:31 idiosyncrat Folks talk about OO with Marpa::R2 and I don't see how that would not make it share the fate of Module::Build.
04:31 idiosyncrat This sort of stuff seemed OK in programming innovation when innovation was essentially defined as playing around with OO.
04:33 idiosyncrat But at this point look at the list of write downs of time and effort due to OO experimentation -- Parrot (with side effects on Perl 6), Module::Build,
04:34 idiosyncrat other stuff I could name but I don't want to gore too many oxen at once.
04:34 hobbs joined #marpa
04:35 idiosyncrat This time and effort could have spent accomplishing cool stuff.
04:37 idiosyncrat OO has had some positive effects -- for example, educating us about the extent to which we can and should eliminate use of globals.
04:39 idiosyncrat But some of the techniques pushed in its name don't have any hope of scaling.
06:07 hobbs joined #marpa
06:12 ronsavage joined #marpa
06:59 hobbs joined #marpa
07:34 rns ronsavage: re http://irclog.perlgeek.de/m​arpa/2015-05-03#i_10541463 -- thanks, duly noted -- https://github.com/rns/kollos-luif-doc/issues/17
07:51 rns in the comment below, that is.
08:14 rns re Module::Build and objects, here is a quote from David Golden, a long maintainer/contributor:
08:14 rns More than just size, Module::Build is complex. The Build.PL file runs configuration and serializes the results into some files, which the Build file uses to reconstruct the original Module::Build object. Arguments can modify properties at any stage. And since Build.PL might really be a subclass, there's a lot of meta object stuff going on just to manage the configuration before ever getting around to the real business of building and in
08:15 rns -- http://www.dagolden.com/index.php/2​140/paying-respect-to-modulebuild/
08:17 rns Once can always say that OOP is ok, it's just used wrongly, but still.
08:18 rns There is that Goedel's word -- "The higher beings are connected to the others by analogy, not by composition".
08:19 rns Interfaces in Go look like a good use of "connection by analogy".
08:19 rns s/long maintainer/contributor/long-time maintainer/contributor/
09:01 DrForr joined #marpa
09:16 DrForr Howdy. How stable is the low-level Marpa API? I'm interested in binding it to Perl6 NativeCall, especially testing callbacks.
09:19 DrForr I know that btyler's been talking about it, but I'm finishing perl6-readline up this weekend and looking for something else to play with.
09:19 btyler (just lurking, so far :)
09:27 hobbs joined #marpa
10:04 rns DrForr: re http://irclog.perlgeek.de/m​arpa/2015-05-04#i_10542751 -- my feeling from working with it is that Libmarpa API -- https://github.com/jeffreykegler/libmarpa -- is very stable and is up for grabs, err, bindings. :)
10:05 DrForr Yeah, that's the log that btyler pointed me to.
10:05 DrForr Okay, I'll look at it this weekend. I'm already working on ANTLR4 bindings.
10:20 rns Great to hear -- are you doing it open-source? I mean I'd like to take a look.
11:50 DrForr Well, https://github.com/drforr/perl6-readline # is the ReadLine binding, though that's nowhere near ready. This weekend I'm cleaning it up and figuring out how to add tests.
11:58 rns Thanks, starred it.
17:49 jeffreykegler joined #marpa
17:51 jeffreykegler DrForr: re http://irclog.perlgeek.de/m​arpa/2015-05-04#i_10542751 -- the Libmarpa API is Marpa most stable and, if you count indirect usage, also its most used.
17:52 jeffreykegler Al current Marpa interfaces are layers over the Libmarpa API.
17:53 DrForr Cool. I'll have to learn the library anyway, but I assume the Macro entries are part of that?
17:53 jeffreykegler It's most significant downside is that it is very low-level -- there are not symbols names, only integer ID's for example.
17:53 jeffreykegler This means you have total flexibilty in a string naming scheme, but it means you have to write your own.
17:54 DrForr I'm not sure how a proper perl6 API would look anyway, so I'm more than happy to have someone else build the next layer up.
17:54 jeffreykegler For a model of a "thin" interface, there is one in Marpa::R2.
17:56 DrForr Good to know. I need to get some other work done before I can attack this, but I've thrown together the basic bindings.
17:57 jeffreykegler Libmarpa in fact uses no string at all, errors are integer codes, rules are integer IDs, token values are integers intended, if necessary to index an array kept at a higher level.
17:57 jeffreykegler So this means you won't have to figure out how to deal with NFG.
17:58 DrForr I didn't see anything that looks like callbacks either, though I didn't yet look into the typedefs.
17:59 jeffreykegler DrForr: Yes, in another effort to make it easy to interface to Libmarpa, there are no callbacks.
18:00 jeffreykegler The evaluator uses an event mechanism -- the upper layer is required to maintain its own evaluation stack, but Libmarpa tells you step by step how to manipulate it.
18:01 DrForr Those of course would be the step enums :)
18:01 jeffreykegler If you're doing a very thin interface, you can just ignore issues of invoking subroutines, types and representation of arguments and results, etc. ...
18:01 jeffreykegler and present the user with the events.
18:02 DrForr Nod.
18:04 jeffreykegler The event interface also allows a bit of value added -- the events optimize for sequence (Kleene star) rules, so followiing the Libmarpa events will save the upper layers some wasted motion as compared to naive stack handling.
18:04 jeffreykegler This all works fine, btw -- Marpa::R2 uses it.
18:05 jeffreykegler Marpa::R2, for its main documented functions uses *only documented* features of the Libmarpa API
18:07 DrForr I've only been working with the documentation so far. Are there any deprecations I should be aware of?
18:07 jeffreykegler Internal Libmarpa methods and features are used only for tracing, debugging, and an advance parse forest traversal/evaluation scheme called ASF's.
18:07 jeffreykegler Indeed, there are deprecations in the docs.
18:08 DrForr Maybe the debugging tools could be a different API, but I won't start there certainy.
18:09 DrForr *certainly
18:09 jeffreykegler My new branch of Marpa, Kollos, will fork the LIbmarpa API, which means the "classic" Libmarpa API will not be seeing many more deprecations.
18:09 jeffreykegler DrForr: you should not need the debugging tools -- there are for debugging Libmarpa itself.
18:11 jeffreykegler For tracing needed at the higher levels, Libmarpa exposes and documents a progress report interface
18:11 DrForr Good 'nuff. Again, I'm not going to get started until this weekend. I'll hang around here when I get started. Most of what's going in NativeCall (after my debugging) is stable...
18:12 jeffreykegler DrForr: I take the term "deprecation" to mean something that is going to be yanked away.  In that sense, Libmarpa may not have *any* deprecations.
18:13 jeffreykegler But the terminal length feature -- the ability to have terminals span Earley sets -- never got any usage -- you might reasonably omit the ability to use variable length terminals from your thin interface.
18:15 DrForr The actual API isn't all that hard to transliterate, but if I have to ignore anything then terminal lengths sound like a good place to skip.
18:16 jeffreykegler Or else one of your users may be the first person in history to discover a user for them!! :-)
18:17 DrForr Entirely possible, I'll keep that in mind.
18:17 jeffreykegler I think in toolkit terms, so I add features without trying to precisely target their use, but one use I thought might happen is intermixing of parser and lexical considerations -- character-by-character tracking of the input.
18:18 jeffreykegler But, while ambiguous tokens have seen considerable use, variable length ones have come even close to being taken up by one of my users ...
18:19 jeffreykegler the main current interface, the SLIF, does not expose this ability ...
18:19 jeffreykegler and in terms of the original thoughts of potential applications, I now believe there are more promising approaches.
18:22 DrForr This might be a good candidate then for a full module then, with variable terminal lengths being a separate class, just thinking out loud.
18:33 jeffreykegler In Marpa's future directions, tokens will be fixed length.  There are *lots* of other unexplored and unexploted possibilities with Marpa.
18:34 DrForr I've gotten tha idea. I'll definitely hang here once I start building this.
19:04 lwa joined #marpa
19:28 jeffreykegler joined #marpa
20:14 aredridel joined #marpa
22:25 ronsavage joined #marpa
22:46 ronsavage jk: In http://irclog.perlgeek.de/m​arpa/2015-05-04#i_10545580 did you really mean 'have come even close' or 'have /not/ come even close'. I suspect the latter.
23:19 jeffreykegler joined #marpa
23:20 jeffreykegler ronsavage: re http://irclog.perlgeek.de/m​arpa/2015-05-04#i_10546998 -- thanks
23:20 jeffreykegler "But, while ambiguous tokens have seen considerable use, variable length ones have come even close to being taken up by one of my users" should be
23:21 jeffreykegler "But, while ambiguous tokens have seen considerable use, variable length ones have *NOT EVEN* come close to being taken up by one of my users

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