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

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!