Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-04

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

All times shown according to UTC.

Time Nick Message
02:42 ronsavage jeffreykegler: Did you mean http://www.perlmonks.org/?node_id=1052010
02:48 jeffreykegler An excellent list of resources, but it does not contain the one I had in mind.
02:48 jeffreykegler I wish my memory wasn't such a sieve. :-)
03:09 jeffreykegler I will say what I like about it -- most C tutorials seem to be written for the world I learned in, which no longer exists.
03:10 jeffreykegler In that world, high-level languages were not basic -- assembler and the machine were considered basics.
03:11 jeffreykegler So a "basic" tutorial in C assumed, if not real knowledge of the problems of working at a very low level, a very low set of expectations about what the computer would do for you.
03:11 jeffreykegler Thankfully, that world no longer exists, so now newcomers to C can be expected to know programming cold, ...
03:12 jeffreykegler but to be a little bit shocked about what it takes to program down to the metal.
06:38 ronsavage joined #marpa
06:42 ronsavage And yet C's survival suggests it struck the right balance between low and high levels.
11:02 LLamaRider joined #marpa
11:03 LLamaRider So, a bit of an exotic question. How hard would it be to use Marpa from a different programming language, like Scala?
11:03 LLamaRider I guess the thin libmarpa layer just remains as-is and I would have to write bindings for the Perl parts
11:03 LLamaRider and I recall Jeffrey saying that is not exactly a trivial task at the moment
15:00 jeffreykegler joined #marpa
15:02 jeffreykegler ronsavage: re http://irclog.perlgeek.de/marpa/2014-04-04#i_8539672 -- taking length of career into consideration, C may be the most successsful language ever.
15:05 jeffreykegler I think it's secret is its focus on the low level -- C's high-level features features range from the merely adequate to the totally non-existent.
15:08 jeffreykegler LLamaRider: re http://irclog.perlgeek.de/marpa/2014-04-04#i_8540446 -- using Marpa from another language would not be that hard -- there's a C language interface to Libmarpa, the core parse engine.
15:09 jeffreykegler The Perl port uses this interface, so it's as solid and tested as anything in Marpa.
15:12 jeffreykegler Also, Peter Stuifzand did a GO language interface, which is on Github, apparently spread over 3 repositories:
15:13 jeffreykegler https://github.com/pstuifzand/go-marpa-thin , https://github.com/pstuifzand/go-marpa , and https://github.com/pstuifzand/go-marpa-gen
15:14 jeffreykegler One issue is that most of the SLIF is implemented at the XS level -- in using libmarpa you get the raw parse, and have to start over with the SLIF.
15:17 jeffreykegler I've never tackled a port, because I can't figure out which one would be valuable -- GO and Scala both seem quite attractive to me.
15:19 jeffreykegler Peter actually under took the GO port, which is the closest thing I've seen to a focused demand for one language
15:20 jeffreykegler Perl users remain devoted to incinerating their time and energy in left parsing, but it's not clear to me any other language community would be better
15:21 jeffreykegler And Perl has CPANtesters, whose importance remains under-estimated.  I read again and again about languages that claim to be catching up to Perl in this respect, with a repository said to be comparable to CPAN ...
15:21 jeffreykegler and that may be true, but I look for any mention of a Scala-testers or a GO-testers and or a Py-testers and find nothing ...
15:22 jeffreykegler which to me indicates it is not even recognized as an issue.
15:23 jeffreykegler It's easy to put a bunch of code on a disk, and not much harder to create an index to it whose quality matches CPAN's ...
15:23 jeffreykegler but CPANtesters is, for me, the life of CPAN.  CPANtesters is why Marpa is a Perl project and at this point remains one.
15:46 yxhuvud jeffrey: comparing with rubygems, which has a similar number of libraries as cpan do, some parts of the gem infrastructure is behind.
15:47 jeffreykegler yxhuvud: but there's no Ruby-testers, I take it
15:47 yxhuvud no. it is up to the gems to keep track of what versions they require.
15:48 jeffreykegler CPANtesters takes the CPAN distributions onto various platforms, runs the test suites, and returns the test reports ...
15:49 jeffreykegler in the early days of Marpa, this allowed me to know that it worked on a wide variety of platforms, most of which I had no access to.
15:49 yxhuvud I'm not certain I understand the work flow.
15:51 jeffreykegler yxhuvud: I think that may be part of the problem -- it's not part of any work flow scheme, and in other language communities testing is thought of as something that takes place within some sort of defined work flow.
15:51 yxhuvud well testing is usually part of the gem build process, and it can also be invoked whenever.
15:52 yxhuvud maybe there is less use of ruby on nonlinux platforms, so the issue ends up smaller?
15:53 jeffreykegler Is the Linux-only focus a decision by the Ruby community, or just the way it happens?
15:55 yxhuvud the latter. but ruby code tends to be pretty cross platform unless it has c extensions, which very few packages have.
15:57 yxhuvud there may still be issues sometimes though, like on systems that don't support proper fork.
16:00 jeffreykegler1 joined #marpa
16:01 yxhuvud I'd guess most of the developers time are spent fighting performance problems and other architechtural problems for the foreseeable future.
16:02 jeffreykegler1 I've a flaky internet connection, btw
16:02 yxhuvud do cpan have anything similar to bundler, where you can control the version of different libraries for an application in a controlled way that doesn't interfere with other apps on the same system?
16:03 jeffreykegler1 Yes.  Perl finally recognized the need for that sort of thing, and there is perlbrew, carton, etc.  I don't use carton (yet?), but do use perlbrew.
16:04 jeffreykegler1 Perl's versioning has been IMHO under-engineered and a scaling problem, but when I bring it up, I get accused of being a Ruby programmer at heart.
16:05 yxhuvud ok. that seems more like a sandbox than bundler is, but I guess it solves the same problem (and some other, that we use other tools to solve in ruby).
16:05 yxhuvud haha
16:07 yxhuvud ruby has had a tendency of breaking things all the time so version resolution and control is getting very controlled (to the degree that an app can specify that it should use a certain package/version on one platform, and a different combination on another).
16:09 jeffreykegler1 From what I hear of it, I think version resolution is something Ruby does right.  Perl's default "hey, just link with whatever, dude" attitude scares me.
16:10 yxhuvud I believe you can get away with it to a larger degree since you focus more on backwards compatibility.
16:12 jeffreykegler1 yxhuvud: Perl
16:12 jeffreykegler1 ... Perlers are good at taking the theoretical unsound and making it work anyway.
16:12 jeffreykegler1 They pride themselves on their contempt for theory in fact.
16:13 yxhuvud well, you get a whole lot of working code anyhow.
16:13 jeffreykegler1 Which since I'm theory-driven makes me a bit of an oddball in the community.
16:14 jeffreykegler1 Yes, exactly, Perlers create things which won't work in theory, but which do work beautifully in practice.
16:18 yxhuvud speaking of which , I should figure out how to implement leo optimization now that I added a test for that RR is optimized away. Or even better, find a way to transfer the idea to the state machine so the dotted rules won't have to be involed. those take away the purity of it :/
16:19 jeffreykegler1 yxhuvud: I abandoned the state machine (I assume you mean the LR(0) states) -- the latest versions of Marpa are back to classic Earley items, plus Leo items as in his paper.
16:20 yxhuvud I find them elegant so far, so I'm keeping them :)
16:21 yxhuvud though I suppose that may change if things get too complicated as I add features.
16:21 yxhuvud I havn't been able to access his paper due to that damned paywall :/
16:22 jeffreykegler1 The hard part of the Leo optimization, by the way, is not the recognizer, but evaluation.
16:23 yxhuvud evaluation? You mean when you use it to generate an actual parse?
16:23 jeffreykegler1 Yes
16:23 jeffreykegler1 And there the Leo paper contains only a few hints -- the evalution strategy is all new with Marpa.
16:23 yxhuvud that is antoher part I havn't done yet - it is strictly a recognizer so far.
16:24 jeffreykegler1 That may explain why you've yet to sour on the LR(0) states. :-)
16:24 yxhuvud mayhap
16:25 jeffreykegler1 It's common in the literature to focus on the recognizer and leave parsing/evaluation as a detail.
16:26 jeffreykegler1 I've found that many promising approaches for recognizers are so much trouble to unravel when parsing/evaluating, all their advantages evaporate.
16:26 jeffreykegler1 The Leo optimization is also a lot of trouble to unravel, but its payoff is huge -- O(n) instead of O(n^2) for vast classes of grammars ...
16:27 jeffreykegler1 extending Marpa's O(n) grammars to every class of grammar any other parsing algorithm in practical use today parses.
16:27 jeffreykegler1 That kind of improvement is worth taking some trouble for.
18:09 LLamaRider jeffreykegler1: I certainly wouldn't want to take Marpa away from Perl, that remains my primary language. But I am tempted to try and bring it to other communities, especially for a $work project
18:10 LLamaRider I will take a read at the Go port and see if it sounds like something I can manage in a weekend, otherwise I'd probably shelve the idea for a later date
19:16 jdurand joined #marpa
19:18 shadowpaste "jdurand" at 88.160.190.154 pasted "Timing for 121992 lexemes using Thin interface" (5 lines) at http://scsys.co.uk:8002/340960
19:20 jdurand Hello Jeffrey, following your advice on G+ I used the thin interface "via" the SLIF, by extending SLR.pm, c.f. https://github.com/jddurand/MarpaX-Languages-XML-AST/blob/master/lib/MarpaX/Languages/XML/AST/SLR.pm
19:20 jdurand Basically the idea is very simple: I call Marpa::R2::Scanless::R::symbol_id to cache symbol_name <-> symbol_id in my code
19:21 jdurand then I used Marpa::R2::Thin::SLR::lexeme_alternative followed by Marpa::R2::Thin::SLR::lexeme_complete, using the hink slr that is returned by Marpa::R2::Scanless::R::thin_slr
19:21 jdurand these three routine mentionned just upper are part of the extension
19:22 jdurand the numbers show that lexeme_complete cost twice more than lexeme_alternative
19:23 jdurand Hmm... a bit less, anyway. On the other hand I have optimized my code a lot, and know other optimisations as well.
19:24 jdurand But conceptually I realize that the less calls to lexeme_complete, the quicker the program. I.e. when writing a grammar it is good if, when possible, to get the less lexemes as possible
19:25 jdurand Concerning XML grammar it is bloated by the "space" lexeme, that I will factorized -;
19:25 jdurand so all in all, these are good numbers
19:32 jeffreykegler1 jdurand: looks good
19:34 jeffreykegler1 LLamaRider: focus on what interests you.  The attitude of programming communities toward parsing can be strange.  I remember particularly (I am withholding names here) ...
19:36 jeffreykegler1 one of us proposing a Marpa parser in some community for a parsing job that wasn't getting done.  Their reply was that they already has parser in one of the cool fashionable languages ...
19:37 jeffreykegler1 which they'd never gotten working, but since it was the parser for that cool language, that was enough for them.
19:39 jeffreykegler1 So you have to have a motive other than outreach, because outreach, even when you have a lot to offer, can easily produce zero results.
22:57 jeffreykegler joined #marpa
23:27 jeffreykegler "Where to get started with formal grammars and parsers?": https://news.ycombinator.com/item?id=1820411

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