Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2014-07-01

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

All times shown according to UTC.

Time Nick Message
00:16 Will_the_Chill joined #perl11
00:16 Will_the_Chill perigrin: Bender bot is gone again?
00:18 Will_the_Chill bulk88: you'll be happy to know that I've chosen a Windows-friendly parser (Eyapp) instead of the kinda-Linux-only parser (perl-byacc) I thought I was gonna use  :-)
00:20 bulk88 yes thats ******* bot is gone
00:31 perigrin he has memory issues
00:31 Bender joined #perl11
00:36 Will_the_Chill haha, a bot with memory issues, save us!  :)
03:50 Will_the_Chill joined #perl11
07:01 ingy joined #perl11
07:41 travis-ci [travis-ci] RPerl Commit By Will Braswell. The build passed. http://travis-ci.org/wbraswell/rperl/builds/28845871
07:52 basiliscos joined #perl11
08:40 dalek joined #perl11
13:06 bluescreen joined #perl11
13:51 rurban1 joined #perl11
14:00 rurban Eyapp looks nice. But it looks like a lot of work, which PPI already does. Not?
14:13 rurban2 joined #perl11
14:17 rurban1 joined #perl11
16:46 Will_the_Chill rurban: quite the opposite actually, PPI is much more complex for low-magic RPerl v1.0 because PPI has no way to formally implement LALR or BNF logic and constructs, the resulting code complexity of limiting PPI to the RPerl grammar seems to grow exponentially from the bottom of the grammar working upward
16:47 Will_the_Chill on the other hand, Eyapp is made for LALR and EBNF, plus Eyapp's %tree directive combined with RPerl's OO implementation makes the Grammar.eyp file look almost identical to the rperl_grammar.txt file!
16:48 Will_the_Chill in other words, Eyapp lets me actually implement the grammar directly and more-gracefully-than-ever-before-possible, so heck yes I'm going to use Eyapp for the low-magic RPerl v1.0
16:49 Will_the_Chill as we move forward with more medium-magic and high-magic syntax and semantics for future versions of RPerl, we will then reconsider using PPI
16:57 Will_the_Chill for low-magic RPerl v1.0, I believe using Eyapp instead of PPI will save weeks of work and thousands of lines of code
17:40 rurban interesting. looking forward to it
17:50 Will_the_Chill yes me too.  :)
17:57 rurban Some of our guys also started using PPI for compiler work. Maybe we should persuade them
18:02 Will_the_Chill what exactly are they doing with PPI?  what compiler(s)?
18:03 rurban They want to parse constructs which are known problems with B::C
18:03 rurban B::CC maybe later when we will partially switch. when -m will be implemented (compile to module)
18:04 rurban Perl::Critic::Compiler rules
18:05 rurban BEGIN block abuse e.g. Doing side-effects in BEGIN blocks which cannot be or should not be restored at run-time. This also applies to rperl
18:05 Will_the_Chill yes you can use PPI with value on the high-magic B::CC issues
18:05 rurban Or magic abuse
18:05 Will_the_Chill RPerl system uses BEGIN blocks and many other magics, RPerl apps are not allowed to use such high magic!
18:06 Will_the_Chill at least, not low-magic RPerl v1.0 apps.  :)
18:06 rurban BEGIN blocks is not really "magic". It's just a compile-time only phase, which does not run at the end-user
18:07 rurban And devs have usually no idea (BEGIN vs INIT)
18:07 rurban Test::More e.g. is a good example of horrible wrong code in BEGIN blocks. Needs to be done in INIT blocks
18:22 Will_the_Chill I will call BEGIN, INIT and other special blocks as being "medium magic" because they can cause unintended and hard-to-measure side effects
18:22 Will_the_Chill so special blocks are not "low magic" and thus not accepted in the grammar for RPerl v1.0
20:44 bluescreen joined #perl11
22:07 d4l3k_ joined #perl11
22:38 rurban1 joined #perl11

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