At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... A scope exit
action is put in place on the control stack with:
pushaction Psub
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the r
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... A scope exit
> action is put in place on the control stack with:
> pushaction Psub
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the relationship to the C opcode?
Thanks,
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> pushmark 12
> popmark 12
> pushaction Psub
I've now implemented these bits. I hope it's correct, specifically, if a
return continuation in only captured, the action handler is not run.
See t/pmc/exceptions.t
Still missing is the throw opco
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:28 AM +0100 11/22/04, Leopold Toetsch wrote:
> Maybe we should name it invoke_return.
Ok. If someone grep's through the tree and just changes all, it's done.
$ find . -type f | xargs grep -w returncc
> We'd talked at one point about swapping interp
At 10:28 AM +0100 11/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Its in and named C since yesterday "return with current
continuation".
Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago t
At 8:57 AM +0100 11/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Exceptions are not, by default, resumable.
Are there non-default resumable exceptions?
Sure. Anything that throws an exception is more than welcome to pass
along a resume continuation if it wants, and I'm OK
On Fri, Nov 19, 2004 at 09:59:18AM +0100, Leopold Toetsch wrote:
: Allowing just one additional object doesn't properly support Python,
: which has two optional expressions for the C statement and Python
: attaches a traceback object to the exception.
:
: OTOH (again from Python's view) raising ju
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
>>Its in and named C since yesterday "return with current
>>continuation".
> Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago the first time.
I've asked for names of the o
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The 'invoke the current return continuation' op apparently got lost
in the blowup. That needs to go in.
Its in and named C since yesterday "return with current
continuation".
Hrm. The name's not right, since
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exceptions are not, by default, resumable.
Are there non-default resumable exceptions?
leo
Dan Sugalski wrote:
Hmm, the first thing to take into the account is that return
continuations can be promoted to the fully blown continuations. This
should affect the handlers in the same way - so exception handlers
could have become arbitrary invokable objects at the point when the
exception
At 10:58 PM + 11/18/04, Tim Bunce wrote:
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
> I'd like pushing exception handlers to remain simple -- the current
> system is almost OK. What I'd like it to change to is:
>
>
At 10:03 AM +0100 11/19/04, Miroslav Silovic wrote:
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to tak
Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> Hmm, the first thing to take into the account is that return
> continuations can be promoted to the fully blown continuations.
Yes. But an exception handler is not a RetContinuation object. It's an
Exception_Handler object (also derived from Continuat
Tim Bunce <[EMAIL PROTECTED]> wrote:
> I guess the HLL compiler needs to ensure that for every push the
> control flow will always pass through a matching pop.
Not necessarily. The handler is pushed onto the control stack. During a
context change (e.g. from a subroutine return), the previous cont
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The 'invoke the current return continuation' op apparently got lost
> in the blowup. That needs to go in.
Its in and named C since yesterday "return with current
continuation".
> I'd like pushing exception handlers to remain simple -- the current
> syste
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to take into the account is that return
continuations can
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
> On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
>
> > I'd like pushing exception handlers to remain simple -- the current
> > system is almost OK. What I'd like it to change to is:
> >
> > push_eh label
> >
> > with poppin
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
> I'd like pushing exception handlers to remain simple -- the current
> system is almost OK. What I'd like it to change to is:
>
> push_eh label
>
> with popping the top exception handler being:
>
> pop_eh
>
> I'm up for better
Now that invocation semantics are fixed and permanent, we need some
cleanup of the code base to round out support. It's also time to get
some things in place that are part of the fallout from it.
The 'invoke the current return continuation' op apparently got lost
in the blowup. That needs to go
20 matches
Mail list logo
