From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Mon, 12 Jun 2006 06:54:24 -0700
On Sun, Jun 11, 2006 at 11:52:14AM -0400, Bob Rogers wrote:
> I notice the following paragraph, vintage late May, in
> pdd23_exceptions.pod:
>
> A C<.begin_eh> directive marks the beginning of a span of
> opcodes which the programmer expects to throw an exception. If
> an exception occurs in the execution of the given opcode span,
> Parrot will transfer control to I<LABEL>.
>
> I assume this means that you intend to replace the current methodology
> of searching for an Exception_Handler object on the control stack when
> an error is thrown with a search through sub metadata.
That's the plan. The upside is that on the non-exceptional case, nothing at
all needs to be done. I just couldn't see the value in making the VM
allocate and free memory blocks on the control stack, over and over, when
no exceptions are occurring.
Yes, that's nice. The downside, though, is that you have to do more
work when it's time to throw, but I agree that this is likely to happen
less often, at least for most error-handling situations. (There's also
a load-time cost, I imagine, but it can't be very large.)
Unfortunately, this is a step backwards from my perspective, as it is
already problematic to use Parrot as it exists now to implement ANSI
Common Lisp error signalling semantics, and any approach based on
metadata (being static) will make it more so. However, I can still
implement ANSI semantics using dynamic binding, C<pushaction>, and
continuations that respect both (which they currently do not), though
the result won't interoperate with error handling in the rest of Parrot.
> How do you envision this interacting with C<pushaction>, e.g.? Currently,
> it is straightforward for find_exception_handler to DTRT WRT other control
> stack entries. Would the metadata also contain information about
> C<pushaction> and such?
I hadn't decided either way about C<pushaction>. Seems to me that either
way will work though. Could you spell out a little more of what you see
as being bad (or harder)?
Actions are dynamic state that must nest properly with respect to error
handlers. So you have to know how many actions to pop & invoke when
unwinding the stack before invoking a given error handler. So it seems
to me that you would also have to lexicalize actions in order to give
find_exception_handler a clue. (Or, more accurately, not to take away
the clue that it has.) But you can't lexicalize actions completely
without removing the ability to invoke a closure as a cleanup action!
> P.S. FWIW, I am asking now because I have begun to work again on
> dynamic binding -- which of course makes this problem worse.
I can't see how. Dynamically bind all you want, but the code of each
subroutine is fixed at compile time. Having static metadata is no sin as
long as as the data that they're meta of are also static.
--
Chip Salzenberg <[EMAIL PROTECTED]>
True, but not all items on the control stack are as static as error
handlers, and they interact to a large degree.
Dynamic bindings in particular require runtime dynamic state (namely,
the saved values), so there still needs to be something on the control
stack to capture it. Of course, one can store metadata that records how
deep the binding stack should be at each handler (relative to the sub
entrypoint), given the right lexical cues in the source. But since (I
believe) we still need binding and unbinding opcodes that do something
at runtime, and could therefore be conditionalized away, or might even
throw an error, this has its pitfalls.
-- Bob
