sprout at cpan
May 13, 2012, 10:06 PM
Post #4 of 4
(54 views)
Permalink
|
On May 11, 2012, at 3:02 AM, Dave Mitchell wrote:
> On Thu, May 10, 2012 at 07:43:14PM -0000, Father Chrysostomos wrote:
>> Re: DAVEM TPF bug-grant report #113
>>
>> Dave Mitchell said:
>>> .../(?{})/....
>>> I took the Executive Decision that...'return' returns from the code
>>> block, not any enclosing sub.
>>
>> I find that counterintuitive. Could you not make (?{return}) an
>> error, at least for now, so we still have a chance to change it later?
>
> Well, it behaves the same way as sort, and indeed uses the same mechanism:
>
> $ ./perl -le 'print sort { return $a <=> $b } 3,2,1'
> 123
> $
>
> So any dieing would have to be special-cased with an extra context flag
> which is handled in the stack unwinding code.
>
> But I can't see any realistic way that return could ever return from the
> enclosing sub (if any). It suffers from the same issue as tie and %SIG
> handlers, in that it's run within a new RUNOPS loop, and you'd need to do
> a longjmp out of that loop and any calling functions (such as S_regmatch
> etc) back to the parent RUNOPS loop; but nothing has set up a setjmp to
> catch that.
Then why can’t the runloop set up a setjmp?
> In addition, the regex engine can now be called directly from
> XS code, so you have no way of knowing what's between you and the original
> RUNOPS loop on the C stack.
If dying is acceptable in that case, then it seems odd that next/last/goto is not, from the point of view of a Perl user.
|
