Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2008-12-08

Perl 6 | Reference Documentation | Rakudo

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

All times shown according to UTC.

Time Nick Message
01:19 ChrisDavaz joined #perl6
01:26 bacek_ joined #perl6
01:34 xuser joined #perl6
01:56 silug joined #perl6
02:25 smallfish joined #perl6
02:41 Entonian joined #perl6
02:52 maasha joined #perl6
03:10 Psyche^ joined #perl6
03:17 araujo joined #perl6
03:23 ChrisDavaz joined #perl6
03:54 alester joined #perl6
04:15 allbery_b I love the smell of bikesheds burning in the morning
05:01 alester CAMELCASE! CAMELCASE!
05:02 alester LOWERCASE AND UNDERSCORES! LOWERCASE AND UNDERSCORES!
05:39 alech joined #perl6
05:53 ChrisDavaz joined #perl6
05:54 maasha left #perl6
06:11 justatheory joined #perl6
06:32 ChrisDavaz joined #perl6
06:42 ashizawa joined #perl6
06:45 justatheory joined #perl6
06:50 DemoFreak joined #perl6
07:00 rakudo_svn r33648 | moritz++ | [rakudo] add a file to spectest.data which the lex refactor made pass
07:24 spx2_ joined #perl6
07:24 spx2 joined #perl6
07:35 sri_kraih joined #perl6
07:52 justatheory joined #perl6
07:58 xinming joined #perl6
08:09 sri_kraih joined #perl6
08:50 pugs_svn r24208 | moritz++ | [t/spec] unfudge overflow.t, all tests pass in rakudo if you have a bigint
08:50 pugs_svn r24208 | moritz++ | library installed
08:52 ihrd joined #perl6
08:52 ihrd hi
08:52 ihrd [,] keep my mind
08:52 ihrd how can I use it?
08:53 moritz_ rakudo: say ([,] 0..3).perl
08:53 ihrd rakudo: say [+] <1 2 3>;
08:53 p6eval rakudo 33648: OUTPUT[[0, 1, 2, 3]␤]
08:53 p6eval rakudo 33648: OUTPUT[6␤]
08:53 moritz_ the first one is actually wrong
08:53 ihrd a! make list from ranges
08:54 moritz_ oh wait, not wrong...
08:54 moritz_ ihrd: not a list, but an array (ie one scalar)
08:55 ihrd I just trying to illustrate what I mean, [+] clear for my
08:55 moritz_ rakudo: for [,] 0..5 { say "a" } # should print only one a\n
08:55 p6eval rakudo 33648: OUTPUT[a␤a␤a␤a␤a␤a␤]
08:55 ihrd oh, yes, array reduction opperators always return scalar
08:55 ChrisDavaz joined #perl6
08:56 moritz_ gotta run now, will report that as a bug later, unless you beat me to it :-)
08:56 moritz_ rakudo: for [\,] 0..5 { .say }
08:56 p6eval rakudo 33648: OUTPUT[Statement not terminated properly at line 1, near "[\\,] 0..5 "␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤]
08:56 ihrd \ do not work now
08:56 ihrd and [**]
08:56 ihrd and [=]
08:57 ihrd rakudo: for [0,1,2] { "a".say }
08:57 p6eval rakudo 33648: OUTPUT[a␤]
09:11 clkao joined #perl6
09:29 iblechbot joined #perl6
09:34 bacek joined #perl6
09:47 justatheory joined #perl6
10:00 zamolxes joined #perl6
10:06 kanru joined #perl6
10:14 ejs joined #perl6
10:26 * ruoso commuting &
10:31 justatheory joined #perl6
10:58 justatheory joined #perl6
11:02 masak joined #perl6
11:08 smg joined #perl6
11:13 mj41 joined #perl6
11:24 riffraff joined #perl6
11:46 sri_kraih_ joined #perl6
11:53 vixey joined #Perl6
12:04 spx2 joined #perl6
12:27 meppl joined #perl6
12:27 ruoso joined #perl6
12:31 Lorn joined #perl6
12:38 ruoso joined #perl6
12:39 ruoso Hello!
12:46 apeiron_ joined #perl6
12:56 hanekomu_ joined #perl6
12:58 pugs_svn r24209 | ruoso++ | [mildew] two tests for fail and Failure
12:58 pmurias joined #perl6
12:59 pmurias ruoso: hi
12:59 ruoso hi pmurias
13:00 rakudo_svn r33649 | util++ | Typo - s/trigonmetric/trigonometric/
13:00 pmurias ruoso: do you think displaying the stack trace at the time each of the leaking objects were malloc'ed would help?
13:01 ejs1 joined #perl6
13:09 ruoso pmurias, only if the leaks are generated by objects created during smop_init
13:10 ruoso because the stack trace will be mostly useless otherwise (unless it's a stack trace of the interpreter itself, but we don't have that kind of debug information yet)
13:14 ashizawa joined #perl6
13:15 pugs_svn r24210 | ruoso++ | [mildew] test for slurpy positionals
13:15 ruoso pmurias, btw... valgrind already presents that stack trace
13:16 riffraff joined #perl6
13:17 ejs2 joined #perl6
13:25 pmurias valgrind++
13:27 ruoso I was wondering
13:27 ruoso what happens if you "require Foo;" and in Foo.pm you have: "module Foo { ... }; module Bar { ... };"
13:28 ruoso ?
13:28 ruoso Does the name "Bar" gets imported also?
13:29 ruoso or is that name visible just on the scope of that file?
13:29 ruoso (besides *Bar, of course)
13:29 ruoso (since it's "our" by default)
13:36 vixey joined #Perl6
13:37 ruoso is it sane to think that "require Foo" will look for a symbol by that name in the lexical scope of the loaded file and create a local alias to it?
13:39 pmurias ruoso: re first question, i can't find anything in S11, having Bar imported seems a bit strange
13:39 ruoso that's what I think too
13:40 ruoso and if that's the case, then my second question is mostly answered
13:41 ruoso S11 seems to imply that there's no "import" routine that is called by "use" in Perl 6
13:43 ruoso er... it actually exists... but it's called EXPORTALL
13:43 ruoso and EXPORT
13:47 ruoso but EXPORTALL is not a subroutine of the package... but a method of Package
13:48 ruoso while EXPORT might be a sub or a method
13:55 ruoso hmm..
13:55 ruoso that doesn't look right
13:56 ruoso rakudo: module  Foo { ... }; Foo.EXPORTALL
13:56 p6eval rakudo 33649: OUTPUT[No exception handler and no message␤current instr.: 'return' pc 12224 (src/builtins/control.pir:39)␤]
13:58 ruoso rakudo: module  Foo { ... }; Foo.EXPORTALL; 1
13:58 p6eval rakudo 33649: OUTPUT[No exception handler and no message␤current instr.: 'return' pc 12224 (src/builtins/control.pir:39)␤]
13:58 ruoso hmmm... weird
13:58 ruoso pugs: module  Foo { ... }; Foo.EXPORTALL; 1
13:58 p6eval pugs: No output (you need to produce output to STDOUT)
13:58 ruoso pugs: module  Foo { ... }; Foo.EXPORTALL; say 1
13:58 p6eval pugs: No output (you need to produce output to STDOUT)
13:58 ruoso interesting..
14:01 moritz_ the "No exception handler and no  message
14:01 moritz_ comes from the ...
14:02 moritz_ rakudo: module Foo { ... }; try { Foo.EXPORTALL }; say 1
14:02 p6eval rakudo 33649: OUTPUT[No exception handler and no message␤current instr.: 'return' pc 12224 (src/builtins/control.pir:39)␤]
14:02 moritz_ rakudo: try { module Foo { ... } }; try { Foo.EXPORTALL }; say 1
14:02 p6eval rakudo 33649: OUTPUT[No exception handler and no message␤current instr.: 'return' pc 12224 (src/builtins/control.pir:39)␤]
14:02 moritz_ oops.
14:11 ruoso_ joined #perl6
14:12 ruoso joined #perl6
14:13 jhorwitz joined #perl6
14:17 riffraff joined #perl6
14:17 mberends joined #perl6
14:19 [particle] joined #perl6
14:25 PZt joined #perl6
14:35 jhorwitz joined #perl6
14:46 iblechbot joined #perl6
14:47 clkao_ joined #perl6
14:51 ruoso joined #perl6
14:54 stephens joined #perl6
14:57 clkao joined #perl6
15:00 pmurias ruoso: are control exceptions and "bad" exceptions seperate
15:00 pmurias that is should we have both a CATCH and CONTROL on stack frames?
15:06 Lorn_ joined #perl6
15:07 PerlJam pmurias: what do you mean "should you"?   Don't you *have to*?
15:12 ruoso_ joined #perl6
15:15 ruoso pmurias, I'm not sure there is a CONTROL
15:15 ruoso but certainly CATCH doesn't catch control exceptions
15:17 PerlJam ruoso ...
15:17 PerlJam A C<CATCH> block handles only "bad" exceptions, and lets control
15:17 PerlJam exceptions pass unhindered.  Control exceptions may be caught with a
15:17 PerlJam C<CONTROL> block.
15:17 PerlJam quoting S04
15:17 ruoso ah... great
15:28 ruoso although I'm not sure how handling return would look like
15:28 ruoso and if a block could intercept someone else's return
15:29 moritz_ ruoso: it could, but only in its own dynamic scope
15:29 [particle] as in sub { map { return; } 1; CONTROL { #{intercept return here} } } ?
15:29 ruoso yeah...
15:29 moritz_ [particle]: exactly
15:30 [particle] yes, i believe it can
15:30 [particle] return is just an exception
15:30 ruoso well...
15:30 [particle] just as die is
15:30 [particle] not sure about exit, though
15:30 moritz_ it would be nice if it were trappable as well
15:30 ruoso [particle], it sure needs to be, since you still have to execute END blocks anyway
15:31 moritz_ ruoso: it's a constant annoyance for things like mod_perl that exit() can't be trapped
15:31 ruoso yeah... indeed...
15:31 moritz_ ruoso: so they have to override CORE::exit
15:31 [particle] well, the spec is unclear about it
15:31 ruoso anyway...
15:32 ruoso how would the default CONTROL block for every routine look like?
15:32 ruoso how does ReturnControlException look like?
15:32 [particle] ruoso: i think tene is working on that for rakudo
15:33 [particle] likely the default CONTROL rethrows return
15:33 ruoso that would be only if every block had a default CONTROL
15:33 ruoso but I don't think you need that
15:33 Tene I'm working on implementation, but I have no clue about what's specced.
15:34 ruoso I think only routines need a Control
15:34 ruoso routines and special operators
15:34 ruoso like "map"
15:34 ruoso that needs to trap "next" and "last" for instance
15:34 [particle] all looping constructs
15:34 ruoso yeah...
15:34 PerlJam Tene: http://svn.pugscode.org/pugs/docs/Perl6/Spec/S04-control.pod   :-)
15:35 Tene PerlJam: great. :)
15:35 nothingmuch joined #perl6
15:36 PerlJam Tene: the lesson is to implement what is specced and ask for clarification on p6l for what's not in the spec.  (It seems everybody needs to learn that lesson.  Sometimes more than once :)
15:37 PerlJam Tene: but you're working at a much lower level than perl6 right now aren't you?
15:37 PerlJam Tene: (though I imagine knowing the high level spec may help guide the low level implementation)
15:38 Tene PerlJam: Right now I'm working on making generic semantics available at the PCT level.
15:38 Tene Once that's done, rakudo can implement its semantics on top of that.
15:38 moritz_ PerlJam: sadly p6l isn't very responsive at times... I asked for Tene about $! some time last week, and still have no single reply
15:39 ruoso CONTROL { when ReturnControlException { if .context.<$?ROUTINE> === $?ROUTINE { $?ROUTINE.leave(|.capture) } else { .rethrow } }
15:39 ruoso how about that?
15:40 PerlJam moritz_: It's because people are afraid to make a decision and Larry is busy  :)   the right way to get people talking is to propose an implementation and tell people that's what you're going to use.  If it's wrong-headed, Larry will speak up eventually; if it's controversial, you'll get lots of feedback; if it's super-simple, you'll get some bikeshedding  :)
15:41 PerlJam (people are afraid to make a decision in the presense of unknownS)
15:42 ruoso I wonder if handling return as a control exception that can be captured won't become a nightmare...
15:42 ruoso it would probably be simpler to assume
15:42 ruoso return 1;
15:42 ruoso is the same as
15:43 ruoso &?ROUTINE.leave(1)
15:44 moritz_ ruoso: that's not the same
15:44 ruoso I know...
15:44 ruoso it's simpler
15:44 ruoso and less powerfull
15:44 ruoso but I'm just afraid of having "return" bouncing over all the CONTROL blocks
15:45 pmurias we will need a pretty powerfull optimizer with all that nasty dynamism in Perl 6
15:46 [particle] yes, the spec is a pretty powerful pessimizer already :)
15:47 moritz_ ruoso: I hope that the presence of a "return" control handler can reasonably be determined at compile time, so that every block can have a bit mask for the most common exceptions instead of a full-blown smart match
15:47 ruoso but you would still be bouncing around,
15:48 ruoso while &?ROUTINE.leave would redirect the flow intantaneously
15:48 ruoso (gah... what was that last word?)
15:48 PerlJam seems like there's a small number of standard control exceptions:  return, next, last, redo, goto, etc.
15:48 [particle] warn, yield
15:48 ruoso take
15:48 ruoso die
15:49 ruoso ok... die is not CONTROL
15:49 moritz_ neither is warn
15:49 [particle] then i guess war... right
15:49 [particle] exit
15:49 moritz_ leave()
15:49 PerlJam no, warn is a control exception according to the spec.
15:49 PerlJam Since warnings are processed using the standard control exception
15:49 PerlJam mechanism, they may be intercepted and either suppressed or fatalized
15:49 PerlJam anywhere within the dynamic scope by supplying a suitable C<CONTROL>
15:49 PerlJam block.
15:50 PerlJam S04:879
15:50 [particle] hrmm.
15:50 ruoso weird
15:50 PerlJam yeah, I thought so too.
15:50 ruoso because warn doesn't leave any block
15:50 ruoso who the hell would capture that
15:51 [particle] a custom warn handler could make it leave a block
15:51 PerlJam ruoso: you really should read the spec though.
15:51 ruoso PerlJam, I already read it, but I keep forgetting it
15:52 PerlJam ruoso: the next paragraph says that "the warning control exception is an abstraction that the compiler is free to optimize away"
15:52 PerlJam ruoso: It's a living document.  I find that stuff I read has changed all the time.
15:53 ruoso right... but...
15:54 ruoso ok...
15:54 ruoso I got it...
15:54 ruoso warn is a control exception that is only handled very far from the code that caused it...
15:56 ruoso and the default handle resumes the continuation after displaying the error
16:01 ruoso joined #perl6
16:09 ruoso hmm... now considering how warn would work
16:09 ruoso we could have return working the same way
16:10 ruoso by default having it handled very back in the dynamic scope
16:13 ruoso now I understand why TimToady says that the exception should not unwind the scope before dealing with the exception
16:15 alester joined #perl6
16:17 ruoso and the default handling code for ReturnControlException does the &?ROUTINE.leave call
16:18 ruoso [particle], moritz_, PerlJam, does it make sense?
16:19 [particle] the default 'return' handler doing '.leave' makes sense to me
16:19 PerlJam yeah, me too
16:19 moritz_ ruoso: not sure... where would that default handler be installed?
16:19 moritz_ in each block that belongs to a routine?
16:20 ruoso moritz_, the default handler would be installed in the prelude dynamic scope
16:20 ruoso that way, it wouldn't be bouncing around to find the handler
16:21 ruoso most of the time, that would be the only CONTROL block defined
16:21 smg joined #perl6
16:23 moritz_ ruoso: I'm not sure if I understand your proposal correctly - I think it would fail on do { CONTROL { given ReturnControlException { 1: } }; { sub foo() { return 2 } } }
16:23 moritz_ in this example the exception from return() never sees the prelude andler, because it's caught by a user defined handler before
16:23 moritz_ but it gets caught too late
16:24 [particle] foo is never called there
16:24 moritz_ [particle]: then insert calling code in the example :-)
16:24 [particle] where?
16:24 masak joined #perl6
16:25 moritz_ at the end, somewhere
16:25 ruoso sub foo { return 1 } {foo(); CONTROL { when ReturnControlException { 1: } }; }
16:25 moritz_ my point is that a prelude defined exception handler only gets triggered when the control exception gets that far
16:25 ruoso yeah... I'm aware of that
16:26 moritz_ if it's intercepted on the way, there's no guarantuee that a 'sub' catches that
16:26 [particle] right, of course.
16:26 elmex joined #perl6
16:26 ruoso it's because the definition of "handling ReturnControlException" then is a bit different
16:26 ruoso it's not handle the return inside this block
16:27 ruoso but handle the return from this point in the dynamic scope onward
16:27 ruoso meaning...
16:27 ruoso this is how we handle "return" from now on
16:28 ruoso not only in this lexical scope
16:28 ruoso which, I think, makes sense
16:28 [particle] it's the caller scope
16:29 ruoso [particle], "dynamic scope" is how we've been calling "caller scope"
16:29 ruoso as opposed to "lexical scope"
16:29 [particle] ok, then that's my understanding, and what i expect
16:30 [particle] so you can stick a CONTROL{} block in a BEGIN{} block, and log all return calls that occur afterwards to a db.
16:30 ruoso so, is everybody ok with "one CONTROL block to rule them all?"
16:30 [particle] or whatever.
16:30 moritz_ ruoso: I still don't see how that works out in the case I mentioned above
16:31 ruoso moritz_, it doesn't... on  purpose
16:31 ruoso the handling of "Return" should take into account what it should do
16:31 moritz_ ruoso: now you lost me :-)
16:31 moritz_ ruoso: but that's ok, you have to implement it, not me :-)
16:32 jferrero joined #perl6
16:32 ruoso let me detail it a little bit
16:33 ruoso sub foo { return 1 }; { foo(); CONTROL { when ReturnControlException { say "Hey, someone is returning, but I'll return 2 instead"; .context.<&?ROUTINE>.leave(2) } } }
16:33 ruoso while the default CONTROL, installed in the prelude would
16:33 ruoso .context.<&?ROUTINE>.leave(|.capture)
16:35 ruoso moritz_, makes sense now?
16:35 moritz_ ruoso: so what would your example return? 2?
16:35 PerlJam How does one throw an exception in Perl 6?
16:35 ruoso foo would return 2
16:35 ruoso yes
16:35 moritz_ ruoso: but it shouldn't, IMHO
16:36 PerlJam Er, how do you throw an arbitrary exception?
16:36 [particle] why on earth shouldn't it? i don't get that.
16:36 ruoso PerlJam, fail
16:36 PerlJam ah, thanks.
16:36 PerlJam I was thinking "throw" and not finding anything useful
16:36 moritz_ because the calling frame of 'foo()' should never see the control exceptoin
16:37 moritz_ because the sub invocation also traps the exception
16:37 ruoso moritz_, so what's the point in capturing CONTROL there, then?
16:37 Limbic_Region joined #perl6
16:38 moritz_ ruoso: that it can be caugth *inside* of the sub
16:38 ruoso moritz_, er...
16:38 ruoso and why on earth would you need that?
16:38 moritz_ so that you can write a map() like functions that catches returns
16:38 ruoso you still can do that
16:39 PerlJam ruoso: in your example foo actually continues to return 1
16:39 PerlJam it needs to be:  sub foo { return 1;  CONTROL { ... } }
16:39 ruoso moritz_, you just need to also handle all the normal "return" control exceptions, besides the special one...
16:39 ruoso PerlJam, that's the way moritz_ is arguing...
16:40 ruoso PerlJam, I'm arguing it can be outside the sub
16:40 PerlJam ruoso: that's the spec
16:40 [particle] where in the spec?
16:40 moritz_ ruoso: what are "normal" and "special" control exceptions?
16:40 PerlJam [particle]: somewhere in S04 :-)
16:40 ruoso PerlJam, would you care to be more precise?
16:40 ruoso moritz_, what do you mean?
16:41 PerlJam ruoso: hold on.
16:41 moritz_ 17:39 < ruoso> moritz_, you just need to also handle all the normal "return"  control exceptions, besides the special one...
16:41 ruoso ah...
16:41 ruoso the normal being the ones you don't want to modify
16:41 ruoso the special being the one you want to make different
16:42 * moritz_ has to catch the bus - if all works out he's back in 15min
16:42 PerlJam Hmm.   It doesn't say specifically that CONTROL blocks must with within the block.  It says that about CATCH blocks, but not CONTROL blocks.
16:43 ruoso CONTROL { when ReturnControlException { if .context.<&?ROUTINE> === CALLER::<&?ROUTINE> { &?ROUTINE.leave(.capture) } else { .rethrow } } }
16:43 ruoso that would do what moritz_ means
16:45 PerlJam but I think that's just an oversight in the writing-of-words department.  All of the other special blocks *must* be within the block they affect.
16:47 ruoso PerlJam, the problem here is the definition of "within"
16:47 PerlJam lexically is how I've always taken it.
16:48 ruoso exactly... when you talk about exceptions, it's "within the *dynamic* scope"
16:48 ruoso not the lexical scope
16:50 * [particle] agrees with ruoso here
16:50 PerlJam Well, I haven't read S04 in detail just now, but my spot reading would indicate that there's an area of the spec that could use some clarification.
16:51 * [particle] agrees with PerlJam here
16:51 ruoso and the use case [particle] pointed out shows how important it is to stick with the "one CONTROL to rule them all" approach
16:51 pmichaud lots of what I'm reading in the scrollback doesn't make sense to me... could someone summarize?
16:51 ruoso pmichaud, basically, how to implement "return"
16:52 pmichaud is particle's use case the 'CONTROL within BEGIN' one?
16:52 ruoso yes
16:52 pmichaud that's one that doesn't make sense to me.  :-|
16:52 pmichaud that would seem to install a CONTROL handler in the BEGIN block, not in the thing that contains the BEGIN block.
16:53 PerlJam pm: that's how I would read it too
16:53 ruoso yes... that's the idea
16:53 pmichaud so then how would a "db log all exceptions"?
16:53 pmichaud that would only catch control exceptions that happen in the BEGIN
16:53 ruoso that happened inside the the BEGIN
16:53 ruoso yes... that's the idea
16:53 pmichaud okay
16:54 pmichaud that doesn't seem all that remarkable to me yet -- perhaps I'm missing something.
16:54 ruoso the most important thing is...
16:54 ruoso we won't have zillions of "automatic" CONTROL blocks
16:54 ruoso and a "return" call wouldn't bounce around untill it finds the correct CONTROL block
16:55 ruoso most of the time, we would have only a single control block
16:55 ruoso that provides the implementation for the default behavior of "return"
16:55 pmichaud this is what rakudo does now, yes.
16:55 pmichaud every Routine gets a single control block.
16:55 pmichaud (by default.)
16:56 ruoso pmichaud, right... that's not what I'm saying
16:56 ruoso the idea would be to have a CONTROL block installed in the prelude dynamic scope
16:56 ruoso that would provide the default behavior for "return"
16:56 ruoso and other control exceptions as well
16:57 ruoso as an exception doesn't unwind the stack before it's handled
16:57 ruoso the default handling code can simply do:
16:57 pmichaud I think an implementation can choose to do it that way, yes.  But I don't think it has to be specced that way.
16:58 ruoso pmichaud, the implications are too large...
16:58 ruoso consider:
16:58 * PerlJam wonders what happens when you provie a CONTROL block, but don't handle the control exception.
16:58 ruoso sub foo { return 1 }; { foo() { CONTROL { when ReturnControlException { #{ make it return a different value } } } } };
16:58 ruoso s/foo()/foo();/
16:59 pmichaud PerlJam: I would expect that, like CATCH, it's rethrown.
16:59 PerlJam (and does it bother anyone else that exceptions are marked as handled implicitly by $! ~~ Thing returning a a true value)
16:59 PerlJam pm: but what does that mean with a return exception for instance?
16:59 pmichaud ruoso:  that's another item that doesn't make sense to me.
16:59 pmichaud the CONTROL block here has nothing to do with the 'return' in sub foo.
17:00 ruoso that's the point... it could have a lot to do wiht it
17:00 pmichaud no, it can't.
17:00 pmichaud every Routine (and a sub is a Routine) has an implicit CONTROL block that will catch and handle the return exception.
17:00 pmichaud so the CONTROL block in your example should never see the return exception.
17:01 ruoso pmichaud, that's exactly the point of debate
17:01 pmichaud you're saying it should?
17:01 ruoso that was basically my point
17:01 pmichaud I think that's not at all what the spec says or implies.  So you're describing a significant change to the spec, if that's the case.
17:02 moritz_ ruoso: I think that sub { ... return } should be exactly analogue to try { ... die }, ie outside of these constructs you never see any (controL) exceptions
17:02 pmichaud basically, you're saying that handlers in outer scopes are able to impact/override the handlers in called scopes.
17:02 PerlJam sub foo { return 1; CONTROL { } }  sub bar { foo(); }  bar();   # What happens?  If the "return is rethrown" in foo(), does that mean we're returning from bar now?
17:02 pmichaud s/outer/caller
17:03 pmichaud PerlJam: I don't think CONTROL { }  replaces the default 'return handler' that is in the Routine
17:03 PerlJam Hmm.
17:03 pmichaud so, if you don't handle it in CONTROL, the return handler still gets it.
17:04 pmichaud (but that's a "top of my head" guess.)
17:04 ruoso pmichaud, so you basically is only able to handle control exceptions that are thrown in the same lexical scope
17:04 PerlJam I guess that's another reason to separate CATCH and CONTROL though as they would have radically different semantics in that case.
17:04 ruoso PerlJam, CONTROL and CATCH are separated
17:04 pmichaud ruoso: I don't think that's what I'm saying.
17:05 ruoso pmichaud, if the Routine always captures it... how would you handle a return from a inner dynamic scope?
17:05 PerlJam ruoso: I know.  I'm saying they only seemed separated by little more than an act of will before.  Now it seems that they have even more reason to be separate.
17:05 moritz_ ruoso: from the inside. From the outside you have wrapping.
17:06 pmichaud what exactly is a "return from an inner dynamic scope"?
17:06 [particle] foo calls bar calls baz
17:06 pmichaud particle:  these are all subs?
17:06 [particle] the return inside baz is affected by the CONTROL block outside foo
17:06 ruoso sub foo { map { return 1 }; CONTROL { ... } }
17:07 pmichaud in ruoso's example, the return is lexically tied to sub foo
17:07 ruoso pmichaud, er...
17:07 ruoso it's an exception...
17:07 pmichaud yes, and that exception is tied to foo
17:07 ruoso an exception is not lexically tied anywhere
17:08 ruoso an exception goes back in the dynamic scope
17:08 pmichaud read the spec
17:08 pmichaud S04: A C<return> always exits from the lexically surrounding sub
17:08 pmichaud or method definition (that is, from a function officially declared
17:08 pmichaud with the C<sub>, C<method>, or C<submethod> keywords).
17:08 pmichaud *lexical*
17:08 ruoso pmichaud, that's how it should behave
17:08 ruoso but that doesn't make the control exception tied to the lexical scope
17:09 pmichaud it has to be tied to it somehow.
17:09 ruoso it doesn't
17:09 ruoso because the exception doesn't unwind the stack
17:09 ruoso so the handling code can access &?ROUTINE
17:09 pmichaud yes, but &ROUTINE is lexical also.
17:09 ruoso &?ROUTINE is the only thing lexical here.... that's my point
17:10 * PerlJam still hasn't gotten used to the mild state of confusion caused by perl 6 issues  :)
17:10 pmichaud I'm not at all saying "unwind the stack", btw.
17:11 ruoso I know... but as it doesn't unwind, it doesn't need to be tied to the lexical scope
17:11 ruoso because it can access the stack and look for lexicals in the handling code
17:11 pmichaud it does so that the 'return' knows it's a "return from foo" and not a "return from map"
17:11 pmichaud (assuming that 'map' has a return handler of its own.)
17:12 ruoso map is a regular routine
17:13 pmichaud presumably, the return() function can find its CALLER's block.  Presumably it can also find its CALLER's routine.  That's the one that should receive the ReturnException.
17:14 ruoso rakudo: sub foo($code) { $code() }; sub bar { foo { return 1 }; return 2 }; say bar();
17:14 [particle] i expect &ROUTINE receives the exception
17:14 p6eval rakudo 33658: OUTPUT[2␤]
17:14 ruoso pmichaud, I think this bug is related to that assumption
17:14 pmichaud I know that rakudo is broken.
17:14 pmichaud Rakudo does not yet tie its return exceptions to a lexically enclosing sub.
17:14 ruoso pmichaud, the point is that it shouldn't
17:14 pmichaud I'm not claiming Rakudo is correct in this respect.
17:15 ruoso it only need to handle "return" in a generic way
17:15 ruoso by looking at the lexical scope of the code that generated the exception
17:15 ruoso and once you do that...
17:16 ruoso the CONTROL block of every routine would be exactly the same
17:16 pmichaud I'm saying the generic way you propose causes difficulty for 16:58 <ruoso> sub foo { return 1 }; { foo() { CONTROL { when ReturnControlException { #{ make it return a different value } } } } };
17:16 alabora joined #perl6
17:16 pmichaud because in this case, the CONTROL block *shouldn't* be invoked.
17:16 pmichaud in having "by looking at the lexical scope of the code that generated the exception", I think we're effectively saying the same thing.
17:17 pmichaud that's what I mean by "tied to lexical scope"
17:17 ruoso but it's not the exception that is tied...
17:17 ruoso it's the handling code
17:17 pmichaud I didn't say that exception was tied.
17:17 pmichaud or if I did, I mistyped
17:17 pmichaud I said that return() is tied.
17:17 ruoso return() is the exceptino
17:18 pmichaud return is a function that generates an exception
17:18 pmichaud (yes, earlier I did say "exception is tied" -- I misspoke)
17:18 ruoso right... right...
17:18 ruoso but the exception, as any exception, need to have a way to access its current contesxt
17:18 pmichaud and when return executes, it generates an exception based on the caller to return()
17:19 pmichaud based on the lexical scope of the caller to return()
17:19 ruoso just like fail
17:19 pmichaud correct, return() and fail() are the same.
17:19 pmichaud (in terms of what they do and how they do it)
17:19 ruoso ok...
17:19 thei0s joined #perl6
17:19 ruoso so, the return function doesn't yet look for &?ROUTINE
17:20 pmichaud in Rakudo?  No, it doesn't do that yet.
17:20 ruoso I mean conceptually
17:20 ruoso it's not the return function that realizes where it returns to
17:20 pmichaud right, it's the lexical scope of its caller
17:21 pmichaud basically, it's the CONTROL block for its caller.
17:21 ruoso it's the handling code for the return control exception, by looking at the lexical scope of the code that generated the exception
17:21 DemoFreak joined #perl6
17:24 ruoso in the following code: sub foo($code) { $code() }; sub bar { foo { return 1 }; return 2 }; say bar();
17:24 pmichaud bar should return 1, iiuc
17:25 ruoso the exception would be handled by the CONTROL block of sub foo
17:25 pmichaud no.
17:25 pmichaud the exception would be handled by the CONTROL block of { return 1 }
17:25 pmichaud since that is return's caller.
17:25 pmichaud foo does not call 'return', foo calls a closure that then calls return
17:27 cognominal joined #perl6
17:37 pmichaud I have to run for a while... bbl
17:41 ruoso pmichaud, uh? you mean that every block would contain a CONTROL block that would handle "return"?
17:41 ruoso not only routines?
17:44 pmichaud I'm saying that if { return 1; } had a CONTROL block, it would get handled there.  But regardless, the return() function can figure out what lexical scope its caller is in, and use that to construct an exception that gets rethrown up to the correct handler.
17:44 pmichaud (which is what I mean by "lexically tied")
17:45 [particle] id it's chasing the caller scope, it's dynamically tied, not lexically tied
17:45 [particle] *if
17:45 pmichaud my caller's lexical scope is not necessarily my caller's caller's scope
17:46 [particle] right. i'll reread your previous comment, then.
17:46 pmichaud depends on what you think of as being the thing "chasing the caller scope"
17:46 pmichaud But foo's  CONTROL/return handler has to be smart enough to only honor ReturnExceptions for 'foo', and rethrow the rest
17:47 pmichaud same as we have to do for C<next LABEL> and C<last LABEL> -- each handler has to discriminate based on more than just the type of exception thrown
17:47 [particle] this is where i think CONTROL should affect ReturnExceptions for 'foo' and everything called inside 'foo'
17:48 pmichaud that's not what the spec says, though.
17:48 jferrero joined #perl6
17:48 pmichaud the spec says that a return always exits from its lexically surrounding sub.
17:49 pmichaud wait, let me rephrase this.
17:50 pmichaud if sub foo() defines its own CONTROL block, then perhaps it should indeed have the opportunity to catch the return exception thrown by $code and do something with it.  However, the default return exception handler has to detect that the ReturnException came from a different lexical scope and therefore should be rethrown to the next handler.
17:50 ihrd left #perl6
17:52 pmichaud (this is assuming that callers can choose to interpose their own CONTROL blocks, which I haven't thought about much yet.  The example ruoso gives is only dealing with default handlers.)
17:54 pmichaud bbiaw
17:54 ryanc joined #perl6
18:01 smg joined #perl6
18:06 ruoso pmichaud, again, the spec only defines the outcome of a return call, it doesn't get into the details of who would be able to catch it with a CONTROL block, and that's what we're arguing about...
18:09 ruoso pmichaud, and it was because of all that potential bouncing around that we came with the idea of making the handling of return generic, and therefore installed in the prelude instead of in each Routine...
18:10 ruoso just like warn does
18:12 ruoso which also got us the possibility of redefining how "return" works in a given dynamic scope
18:13 ruoso and that was [particle]'s use case for CONTROL within BEGIN
18:39 ejs joined #perl6
18:51 ejs1 joined #perl6
18:56 Exodist joined #perl6
18:57 vixey joined #Perl6
18:59 [particle]1 joined #perl6
19:01 pmichaud ruoso:  if we say that   sub foo { ...; return 1; }   { foo();  CONTROL { ... } }   means that the CONTROL block has the ability to modify foo's return result, doesn't that imply the same for every sub that foo calls, and that those subs calls, and so on?  I.e., that we'd really be causing *every* sub called by foo to return some other value?
19:02 pmichaud and if it doesn't, doesn't it mean that every sub that foo calls (and that they call) have to go through multiple CONTROL blocks to find the correct return result?
19:04 [particle]1 pmichaud: yes, every sub foo calls in that example will execute the CONTROL block specified
19:05 pmichaud so all of them would have their return values modified?
19:05 [particle] yes, if that's what the CONTROL block does
19:05 [particle] when ReturnException { return 2 }
19:05 pmichaud how would I say "only catch ReturnException for foo?"
19:06 pmichaud and if the CONTROL block doesn't handle ReturnExceptions, does that mean that every return statement in the calling chain for this block ends up effectively having to run two handlers, instead of one?
19:06 [particle] &ROUTINE.caller === &BLOCK ??
19:07 PerlJam I see there's been no resolution yet :)
19:07 pmichaud well, I was away for about an hour.
19:07 [particle] that's the nature of asynch communication
19:07 pmichaud [particle]: I don't see how &ROUTINE.caller == &BLOCK helps me here.
19:08 [particle] catch handles anything that happens at any point inside try.
19:08 [particle] control handles anything that happens at any point inside routine
19:09 pmichaud which routine, in this instance?
19:09 pmichaud I see no &ROUTINE here
19:09 pmichaud (except for maybe the outer assumed "main" routine.)
19:10 [particle] sorry, i mean in this case the anonymous block { foo(); CONTROL { ... } }
19:10 pmichaud how does that tie me to 'foo'?
19:10 pmichaud i.e., so that I can "only change foo's return value"?
19:11 [particle] i'm trying to work that out.
19:11 [particle] how do you catch an exception in try only if it's directly called from the try block?
19:11 pmichaud I think the big issue with trying to make 'return' work like 'warn' is that return is common, while warn is... well, exceptional.
19:11 pmichaud try { foo(); CATCH { ... } }     # catches any exception thrown by foo, or things called by foo
19:12 [particle] right, and i'm saying do { foo(); CONTROL { ... } } # catches any return thrown by foo, or things called by foo
19:12 pmichaud and I'm saying that's wrong
19:12 PerlJam [particle]: why?
19:13 pmichaud because in the case of Routines, each Routine has its own "assumed" control handler that will catch return exceptions.
19:13 pmichaud It doesn't look to its caller to provide one.
19:13 [particle] that's where ruoso and i see it differently than you do
19:13 pmichaud this is different from 'warn', where the model is that there's an assumed outer control handler, and a block is allowed to interpose its own 'warn' handler if it wishes.
19:15 [particle] you're saying that by default every Routine gets a CONTROL block, which affects only that Routine...
19:15 pmichaud not necessarily a CONTROL block
19:15 pmichaud a return exception handler
19:15 [particle] and there's one default CATCH block that handles all war.
19:15 [particle] *warns
19:16 pmichaud yes, the spec explicitly says this last point.
19:16 [particle] yes, the last point is clear in S04
19:16 pmichaud but the difference is this...
19:16 pmichaud with warn(), we know that our callers are allowed to intercept and change what happens -- i.e., we _expect_ something in our callers to handle the warning.
19:16 [particle] i'm wondering... do CONTROL blocks only affect the current scope, and CATCH blocks affect the whole chain?
19:17 pmichaud with return(), we expect that the Routine we're in will catch the exception, and that anything our Routine's callers do won't have any affect on our return value.
19:17 PerlJam [particle]: since you seem to understand things better than I do, perhaps you should ping p6l on this issue?  :)
19:18 pmichaud I'm thinking that CONTROL and CATCH affect the whole chain
19:18 [particle] pmichaud: warn is expected to resume the current continuation, return is expected to call the 'to' continuation
19:18 [particle] more precisely, return is expected to '.leave' the current Routine
19:19 pmichaud if that's the case, then that's another reason why they're different, and why they should be treated differently.
19:20 [particle] i'm saying there's a default CONTROL in the prelude that makes a return exception call &ROUTINE.leave
19:20 pmichaud ...but &ROUTINE is lexical...?
19:21 [particle] &ROUTINE is dynamic
19:21 pmichaud in this case, what &?ROUTINE are you referring to?
19:21 [particle] it changes every time you enter a Routine
19:21 pmichaud sure
19:22 pmichaud but it's static at compile time
19:22 ruoso re: where does &?ROUTINE come from: $exception.scope.<&?ROUTINE>
19:22 pmichaud where exception gets its scope from...?
19:22 pmichaud sub return(...) { ... }   ?
19:23 ruoso from the continuation that is waiting for the handling code to decide what will happen
19:23 pmichaud ...what continuation?
19:23 ruoso the code that thrown the exception
19:23 pmichaud the exception itself is created by the return() function.
19:24 pmichaud in fact, it's return() that throws the exception.
19:24 pmichaud surely you don't mean the scope of &return itself.
19:25 ruoso sure I don't
19:25 pmichaud so, where does exception get its scope from?
19:25 ruoso pmichaud, the point here is that the return exception is an exception like any other control exception
19:25 ruoso warn is a control exception
19:25 ruoso and the user might define new control exceptions
19:25 pmichaud but they're *different* control exceptions, with different semantics.
19:25 pmichaud in the sense that return exceptions are caught and handled by routines, but warn exceptions are not.
19:26 ruoso the thing is that this difference is defined by the code that handles them
19:26 ruoso not by themselves
19:26 ruoso one could catch warn control exceptions and turn them into exit() calls
19:26 pmichaud sure, but that's not a default behavior.
19:26 pmichaud we're talking about what happens by default.
19:27 ruoso we're talking about what happens conceptually
19:27 ruoso conceptually, a control exception can only be handled by a CONTROL block
19:27 pmichaud conceptually, routines catch return exceptions (that are targeted at that routine), but don't catch warn exceptions.  That's the difference.
19:27 ruoso we know you are saying this, from the start of the discussion\
19:28 ruoso you're saying that Routines have a built-in CONTROL block
19:28 pmichaud did you see my note above about  { foo();  CONTROL { ...change return value... } }     means that it would change the return value for not only foo, but everything that foo calls?
19:28 rdice joined #perl6
19:28 ruoso pmichaud, yes... I didn't comment on that because I second [particle]'s comment
19:28 pmichaud which is...?
19:29 ruoso there is no built-in CONTROL block in every Routine
19:29 ruoso therefore, that CONTROL block would see every return exception thrown inside that dynamic scope
19:29 pmichaud so, you accept that by writing CONTROL { ...change return value...}  we are in fact changing the return value of every routine called from that scope, and the routines that they call as well?
19:30 ruoso yes
19:30 pmichaud sub foo() { if bar() == 2 { say 'yes' } };   sub bar() { return 1; }   { foo(): CONTROL { ...change return value to 2... } }
19:31 ruoso ruoso's_eval_bot: yes
19:31 pmichaud sub foo() { if bar() == 0 { say 'yes' } };   sub bar() { return 1; }   { foo(): CONTROL { ...change return value to 0... } }
19:31 ruoso ruoso's_eval_bot: yes
19:32 pmichaud ...but wouldn't the result of infix:<==>(bar(), 0)  be zero?
19:32 pmichaud since we changed the return value of *every* called sub?
19:32 ruoso alright... that's why changing the value of every called sub is dumb
19:32 pmichaud and that's why this interpretation for CONTROL doesn't really make sense.
19:32 ruoso it does...
19:33 ruoso because it provides a consistent handling of control exception
19:33 pmichaud the way I'm talking about is also consistent.
19:33 pmichaud it's just differently consistent.
19:33 ruoso and avoids the need for every routine to check if it's the routine that should return
19:34 pmichaud false.
19:34 ruoso why?
19:34 pmichaud in the above case, if I wanted to check and only change the return value for foo(), how would I do it?
19:34 pmichaud no matter what you say, every routine that foo calls will end up doing that check.
19:35 ruoso CONTROL { when ReturnControlException { if .scope.<&?ROUTINE> ===  &foo { #{chage} } else { .rethrow } } } }
19:35 pmichaud yes, every routine that foo calls ends up doing that check.
19:36 ruoso pmichaud, but that will only happen *IF* I implement a custom CONTROL
19:36 PerlJam Are exceptions "suspended" during the CONTROL block?
19:36 ruoso most of the time, it would reach the prelude block which looks like
19:36 ruoso yes
19:36 ruoso CONTROL { when ReturnControlExceptin { .scope.<&?ROUTINE>.leave(|.capture) } }
19:37 ruoso PerlJam, the exception handling code can decide that this exception is not important and that the code can resume
19:38 ruoso i.e.: warn
19:39 PerlJam ruoso: I was thinking more of Pm's example where infix:<==> changes meaning actually.
19:40 PerlJam The more you guys talk, the less I think I understand.
19:40 ruoso pmichaud, in fact, every Routine could have this same handling code
19:41 ruoso but it just feels awkward that every Routine has the same generic CONTROL block installed
19:41 PerlJam ruoso: your version seems to put some burden on the programmer to not screw up when they modify  the return value;  Pm's way doesn't put any burden on the programmer.
19:41 PerlJam (except for the one routine where they want the value modified, but presumably that's why they wrote the handler)
19:42 ruoso I'm aware of that, it's a change of the meaning of "catching return"
19:42 pmichaud I think that's ultimately what it comes down to... as a P6 programmer, I don't expect   CONTROL { ... }     to modify the handling of "normal" things like return() in the subroutines that I call (which may come from other packages or lexical scopes).
19:42 ruoso er... I don't expect anything "normal" to use CONTROL
19:43 pmichaud my point remains.
19:43 ruoso It is indeed a question of "what does it means to capture the return control exception"
19:44 ruoso you are saying that it applies to that Routine only
19:44 ruoso and we are saying that it applies to the dynamic scope onward
19:44 ruoso *inner dynamic scope
19:44 pmichaud ...except one would use to CONTROL to capture warnings, and that's "not abnormal"
19:45 pmichaud using CONTROL to capture warnings might indeed be quite common.
19:45 ruoso one can still capture warnings without touching return
19:45 pmichaud sure, but it does show they're not "abnormal"
19:45 ruoso I don't see a difference for that matter
19:46 lichtkind joined #perl6
19:46 pmichaud I'm still curious to know what you mean by "scope of the exception"... but I don't doubt there's some weird way to come up with one.
19:46 PerlJam ruoso: Assuming both points of view are equally valid, why should your way be *the* way?
19:46 pmichaud inside of &return, it would have to be something like "the Routine that contains my CALLER's scope"
19:46 PerlJam pm: same question  :)
19:46 ruoso pmichaud, in SMOP every continuation has an API that should provide access to its lexical scope
19:47 PerlJam (I ask because it seems to me that he main benefit for ruoso seems to be an implementation detail)
19:47 ruoso PerlJam, it also allows some different things to be done
19:47 pmichaud (such as modify the return value of any called sub)
19:48 PerlJam ruoso: other than what pm just said, what else?
19:48 ruoso pmichaud, or, in a less dumb example, debug the return exceptions...
19:49 pmichaud ruoso: I'm just wondering what that "callers outer scope" would look like as a Perl 6 variable.
19:49 ruoso CALLER::OUTER ?
19:49 pmichaud I guess I mean ROUTINE
19:49 pmichaud so CALLER::ROUTINE
19:49 ruoso CALLER::<&?ROUTINE> actually
19:50 PerlJam I hope TimToady reads this conversation and there's enough contrast to be useful  :)
19:50 PerlJam (unless he's already made up his mind but hasn't documented it)
19:50 pmichaud there is.  the question is whether Routine's have an implicit return exception handler or whether they share a common one.
19:50 ruoso indeed, and I think we pretty much exhausted the possible argumentation...
19:51 ruoso it's now a matter of language design
19:51 pmichaud yes, we'll just have to wait for a TimToady decision
19:51 pmichaud I can actually go either way from an implementation perspective, although getting CALLER::<&?ROUTINE> is going to be tricky in Parrot.
19:52 ruoso pmichaud, but you need to support anyway...
19:52 pmichaud (and then grabbing its return continuation is also tricky -- we'll have to add some more introspection>
19:52 ruoso pmichaud, even if the return is not implemented that way, CALLER::<&?ROUTINE> should be valid Perl 6
19:52 pmichaud yes, difficulty of implementation is not where I'm coming from.
19:53 ruoso as well as CALLER::<&?ROUTINE>.leave(1,2,3)
19:53 pmichaud I'm not at all taking a position because one is easier in Parrot and another is not.
19:53 ruoso I know
19:54 PerlJam pm: It's funny because "your way" is how I've always assumed it to be and it wasn't until today that I realized it wasn't spelled out as such in S04.
19:54 pmichaud pj:  as you've discovered, there's a lot of stuff like that in the synopses
19:54 lichtkind jnthn: held perl 6 talk with one entire slide about you :)
19:54 jnthn lichtkind: Oh no!
19:55 lichtkind yes !
19:56 lichtkind many inhabitants of this channel had at least one slide :)
19:56 jnthn Ah, phew!
19:56 ruoso heh
19:56 pmichaud ...at least?  some had more than one?  ;-)
19:56 * jnthn didn't want to be singled out for :-)
19:56 lichtkind pmichaud: you had :)
19:56 jnthn ...for incomplete sentances.
19:57 lichtkind pmichaud: dan and allison too
19:57 pmichaud hmmmmmm
19:57 pmichaud was this one of those presentations where the less someone was mentioned, the better for him/her?  ;-)
19:57 PerlJam lichtkind: and simon?
19:58 lichtkind PerlJam: cosenz? only the joke and the Lolcode thing
19:58 ruoso lichtkind, can you please end the drama and post a link to the slides ? :P
19:58 lichtkind its german
19:58 PerlJam lichtkind: I was thinking the lolcode thing would have deserved a mention for him  :)
19:58 lichtkind pmichaud: no it was a small workshop and more of an open discussion
19:59 ruoso lichtkind, google translate is ok for slides, usually
19:59 lichtkind PerlJam: yes but the parrot name is also his fault
19:59 lichtkind http://wiki.perl-community.de/bin/view/User/HerbertBreunung
19:59 lichtkind its the last one
19:59 PerlJam lichtkind: yes, but that was *years* ago  ;)
19:59 lichtkind PerlJam: it was a history lesson :)
20:00 lichtkind ruoso: no drama just wanted initially tease jnthn
20:00 * [particle] is back from phone-land
20:01 ruoso lichtkind, ;)
20:01 lichtkind ?
20:02 PerlJam lichtkind: heh, I like the title slide.
20:02 lichtkind PerlJam: yeah ist nice but a bit negative
20:02 jnthn phew, nothing too bad!
20:02 jnthn At least it was a photo of me *before* hacking on Rakudo had turned me white...
20:03 jnthn ooh...I should get food before the food places close
20:03 jnthn bbl
20:05 lichtkind :)
20:06 lichtkind jnthn: my point of this slide was that rakudo does progress becuase you pushing  it a lot
20:11 thei0s hm, are these http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf up 2 date or was something removed or added? :)
20:11 PerlJam thei0s: I'm pretty sure it's *not* up to date.
20:11 * PerlJam looks anyway
20:12 PerlJam yeah, it's old.
20:12 donaldh joined #perl6
20:17 ejs1 joined #perl6
20:20 ejs joined #perl6
20:21 lichtkind thei0s: yes its this old table, this slide only is ment to be funny :)
20:21 lichtkind but it was really an eye catcher
20:23 thei0s :)
20:32 pmichaud question about CONTROL forwarded to p6l -- hopefully it'll get some responses there.
20:34 smg joined #perl6
20:44 ruoso joined #perl6
20:47 ruoso pmichaud++ # very concise way of doing that question...
20:48 pmichaud yes, I like to just put it out there with a contrast and see how people respond.  :-)
20:48 [particle] indeed, pmichaud++
20:48 pmichaud your example made it easy to come up with that question.
20:50 ruoso and the way you asked also exposed the most visible side-effect to the actual question
20:50 ruoso which should help gettin a straight answer
20:54 pmichaud allison: pdd22io branch now has only one failing rakudo spectest
20:54 pmichaud t/spec/S16-filehandles/io_in_whil    1   256    13   26 200.00%  1-13
20:54 pmichaud I'm happy to regress that one test, as we know we need to re-do Rakudo's I/O anyway.
20:55 pmichaud oops, wrong chan
21:46 alech joined #perl6
22:17 alech joined #perl6
22:22 dr_df0 joined #perl6
22:30 moritz_ rakudo: for [,] 1, 2, 3 { say 'a' }
22:30 p6eval rakudo 33671: OUTPUT[a␤a␤a␤]
22:30 vixey omg I'm really excited about perl 6 :D
22:30 lambdabot vixey: You have 1 new message. '/msg lambdabot @messages' to read it.
22:30 vixey oops
22:31 vixey which implementations are being worked on most atm?
22:31 vixey STD and elf I guess .. and ?
22:32 Limbic_Region vixey - see http://perlmonks.org/?node_id=690945
22:32 moritz_ vixey: rakudo
22:33 vixey idk but I have some irrational thing against rakudo
22:33 vixey I think it's because it was so new when I looked at it..
22:35 moritz_ hald a year ago it was a real pain to program with rakudo
22:35 moritz_ s/hald/half/
22:35 ft joined #perl6
22:35 moritz_ now it's much better, IMHO
22:40 pugs_svn r24211 | moritz++ | [t/spec] clean up and fudge reduce-metaop.t for rakudo.
22:44 pugs_svn r24212 | hinrik++ | [util/perl6.vim] add a keyword, highlight misplaced multiline comments as errors
22:45 zonkers joined #perl6
22:45 zonkers rumor is that perl6 will be out at the end of the year?
22:45 vixey I heard it was Christmas :P
22:45 moritz_ zonkers: if you mean "next" by "the", then maybe yes
22:46 vixey but I don't expect Dec 2008
22:46 moritz_ zonkers: the parrot 1.0 release is planned for march, though
22:47 smg joined #perl6
22:48 zonkers will there be a perl 5 that runs on parrot?
22:48 PerlJam zonkers: if you write it.
22:48 PerlJam zonkers: my guess would be "no"
22:48 moritz_ that's unlikely; more likely parrot will link with perl interpreter, so that you can use them together
22:49 moritz_ but that's certainly not a feature of 1.0
22:49 PerlJam zonkers: There will be enough of a perl5 parser in perl6 that it will be able to detect the difference and do something appropriate I bet .
22:50 rakudo_svn r33672 | moritz++ | [rakudo] add tests for meta reduction ops to t/spectest.data
22:50 zonkers what is going to run on parrot?
22:50 zonkers when it is released?
22:51 PerlJam I think you're coming at this from the wrong angle.
22:51 PerlJam when parrot reaches 1.0 it will be a stable platform for language developers.
22:51 PerlJam There are already compilers for perl 6, tcl, and a few other languages that run on top of parrot.
22:52 PerlJam the 1.0 release just marks when the ground won't shift so much beneath them.
22:52 zonkers ok so parrot is very similar to the CLR in .net or more like the DLR?
22:52 moritz_ zonkers: more like DLR, I guess
23:03 zonkers i think the feature i'm craving the most is more lightweight threading from perl
23:04 PerlJam why? threads are a mistake.
23:05 PerlJam (okay, I exaggerate a little ;)
23:05 moritz_ sadly there aren't many alternatives
23:05 zonkers i'm able to use them to some degree and it works well for me
23:05 moritz_ STM hasn't worked out too well in practise
23:08 PerlJam Parrot has threading to be worked out by Jun 2009 in their roadmap
23:09 PerlJam https://trac.parrot.org/parrot/wiki/ParrotRoadmap
23:10 pugs_svn r24213 | moritz++ | [t/spec] a test for [%] (meta reduce modulo)
23:11 zonkers wow, that's a 6-7 months of 2009.   i'm excited to see the new stuff.   thanks
23:14 dr_df0 zonkers: if you want to read on parrot internals there are great docs in the SVN repo
23:15 dr_df0 zonkers: PCT is quite impressive IMHO
23:15 zonkers that stuff puts me to sleep. I'd rather concentrate on creating  programs in perl
23:16 zonkers my co-workers can't believe how productive i am
23:16 dr_df0 but writing grammars for new languages involes writing in NQP (Not Quite Perl) which is modeled after Perl6 specs
23:16 dr_df0 so you may say, that's Perl programming :)
23:16 zonkers ok
23:17 zamolxes joined #perl6
23:17 zonkers thanks for the info
23:17 zonkers have a great holiday
23:17 zonkers left #perl6
23:17 moritz_ there are also many perl5 related tasks in parrot, because the build and test system uses perl 5 heavily
23:22 sri_kraih joined #perl6
23:43 zamolxes joined #perl6
23:55 dr_df0 bed++

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

Perl 6 | Reference Documentation | Rakudo