Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-03-23

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

All times shown according to UTC.

Time Nick Message
11:32 ilbot3 joined #marpa
11:32 Topic for #marpa is now Logs: http://irclog.perlgeek.de/marpa/today Nopaste: http://scsys.co.uk:8002/marpa Stable release: https://metacpan.org/pod/Marpa::R2 Developer release, 2014-02-14: https://metacpan.org/releas​e/JKEGL/Marpa-R2-2.079_015 Source: https://github.com/jeffreykegler/Marpa--R2
11:33 ronsavage joined #marpa
15:25 jeffreykegler joined #marpa
16:23 jeffreykegler I've been trying to comment on a Perl bug: https://rt.perl.org/Public/​Bug/Display.html?id=121392
16:24 jeffreykegler My problem is that I can view it as "guest", but not comment.  When I log in, I am even allowed to view it.
16:24 jeffreykegler I've contacted perlbug-admin, but in the meantime ...
16:25 jeffreykegler if anyone can comment on a perlbug, let them know about this blog posts of mine, which discusses that issue: http://jeffreykegler.github.io/Ocean-of-Awar​eness-blog/individual/2011/10/perl-and-parsi​ng-12-beating-up-on-the-use-statement.html
16:26 jeffreykegler Also somewhat relevant are http://jeffreykegler.github.io/Ocean-of-A​wareness-blog/individual/2011/09/perl-and​-parsing-9-use-and-the-ruby-slippers.html and http://jeffreykegler.github.io/Ocean-of​-Awareness-blog/individual/2011/10/perl​-and-parsing-10-use-the-easier-way.html
16:26 jeffreykegler Thanks!
16:28 jeffreykegler Perlbug 121392, for the curious, is about a much underestimated problem with legacy parsers -- because they require a lot of hacks, you know longer necessarily know exactly which language you are parsing ...
16:29 jeffreykegler Testing often makes sure that most code that the designer wants parsed is being parsed, but often there is not testing for the opposite -- successfully parsing syntax that you do *not* want parsed.
16:30 jeffreykegler This can result in the inadvertent creation of unintended syntax "features" which, when discovered, pose a choice -- either leave the "feature" in, or risk breaking code that relies on it.
16:32 jeffreykegler This actually is worse for language evolution than failure to parse -- the failure to parse you can fix, and move forward ...
16:32 jeffreykegler Parsing unintended "features" can trap you.
17:14 yxhuvvd It could be argued the real trap is worshipping backwards compatibility too much.
17:16 jeffreykegler In a context where you have a huge codebase that nobody understands, a mission critical-app and an overwhelmed staff, you learn to worship backward compatibility
17:16 jeffreykegler and there are a lot of those situations out there
17:21 jeffreykegler Re Marpa itself & backward compatibility -- I try to get the best of both world's ...
17:22 jeffreykegler in each named release (Marpa::XS, Marpa::R2, etc.), I try to be very strict about preserving backward compatibility.
17:23 yxhuvvd that situation will fail sooner or later anyhow. either when that codebase has to be changed or when some staff quits, or when the machine it runs on die and the system needs to be put into place again.
17:23 jeffreykegler But periodically, I create a new module, at which point I feel free to break anything and everything.
17:23 yxhuvvd mission critical apps simply cannot be allowed to be not understood.
17:25 yxhuvvd which isn't saying it doesn't happen, but it is the situation that is wrong - not evolving language.
17:26 yxhuvvd I suppose I am quite colored by Ruby community thinking in this though - perls typical use case is different which may lead to different conclusions
17:28 jeffreykegler Ruby as I understand it, is strict in a sense -- while I'm told new gems are free to break compatibility ...
17:28 jeffreykegler versioning is very strict, so there are few surprises.
17:29 jeffreykegler Btw, back to extolling Marpa's virtues :-) ...
17:29 yxhuvvd historically, that has not really been the case. I've had Rails, the biggest application by a large margin die on me due to a update of a minor version .. They have changed policy now - perhaps it will be more predictable now.
17:30 jeffreykegler I hope Marpa will bring in a technology where new language creation is no longer A Big Big Deal ...
17:31 jeffreykegler which means you don't have to face the evolution vs. compatibility dilemma -- you can just spin off a new language
17:32 jeffreykegler With current parsing technology, it's so hard to get a reasonable language working, once you've done it, you want to get the most out of that investment ...
17:32 jeffreykegler so any new idea, you prefer to add it to an old language, rather than just fork something new.
17:32 jeffreykegler I hope Marpa will change these tradeoffs.
17:37 yxhuvvd yeah, some of the existing languages have parsers that are pretty horrible. being able to avoid that would be pretty huge.
17:37 yxhuvvd I wonder how much performance is lost in those overly complicated parsers.
17:38 jeffreykegler I'm thinking of some very radical stuff -- for example if you look at Jean-Damien's C parser ...
17:39 jeffreykegler you see that you can, in a few hours, create your own C variant.
17:40 jeffreykegler You'll need a backend, but that's doable, and for quick
17:40 jeffreykegler 'n dirty you can just transpile to C.
17:41 * yxhuvvd tries to remember the name of the language where you have programmatic access to parse rules.
17:41 yxhuvvd in a modifiable way.
17:41 jeffreykegler LISP claims to, but it's not really a parsed language
17:42 yxhuvvd no, this was not a lisp. just a few years old.
17:43 jeffreykegler lang5, which I recently mentioned and has me intrigued, also has a syntax extension feature, which is borrowed from FORTH
17:44 jeffreykegler lang5 on the surface is a combination of APL and FORTH
17:45 jeffreykegler Those were two very interesting languages, but most practitioners, even many of those who found them enticing, found their approaches just didn't scale
17:47 jeffreykegler Ullman, lang5's author, apparently liked both FORTH and APL, and decided to combine them
17:49 jeffreykegler To put it in context, Ullman's stated goal is teaching about languages, and not scareing C and Java out of the business.
17:49 jeffreykegler As a language, I frankly don't think I'd ever use lang5 for anything ...
17:50 jeffreykegler but in terms of suggesting future directions, I find it very, very interesting and inspiring.
18:06 jeffreykegler To clarify the preceding, what intrigues me is not the syntax itself, but the way the language is implemented -- the implementation is very hack-friendly -- you could take it in lots of different directions.
21:28 jeffreykegler joined #marpa
22:02 ronsavage jeffreykegler: A typo in your text: "you know longer necessarily know". Change the 1st 'know' to 'no'.
22:04 jeffreykegler ronsavage: I don't think there is an easy way to change the log.
22:05 ronsavage jeffreykegler: Understand. I was just harping about a typo.
22:05 ronsavage As for allowing 'use VERSION MODULE', surely it would have been better to not allow that in the first place?
22:06 jeffreykegler My point being that if your parser is hack-based, rather than syntax-driven, it is hard to know what you are allowing.
22:07 jeffreykegler This is a big problem with left parsing (recursive descent, etc.)
22:08 jeffreykegler In Perl's case it is not left parsing, but LALR, but they try to extend it with hacks as if it were recursive descent, which creates the same kind of problem.
23:25 jeffreykegler1 joined #marpa
23:48 ronsavage Yes, synatx-driven it must be. But that includes not arbitrarily extending the syntax...
23:48 ronsavage synatx aka syntax.
23:49 jeffreykegler1 I describe what happened in more length in my blog post (which is why I wanted to add mention of it to the perl bug report) ...
23:50 jeffreykegler1 but it happened as a by-product of the parsing logic -- I am pretty sure nobody decided to extend the syntax in this way ...
23:51 jeffreykegler1 it is very common with the extra procedural logic that you have to add to traditional parsers that it is so complex that it is almost impossible to fully understand its effects
23:51 jeffreykegler1 my blog post points out where the code is
23:52 jeffreykegler1 and a glance at it will make it clear why unintended syntax extensions could happen.

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