At 4:42 PM -0700 4/22/02, Steve Fink wrote:
>On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
>> G'day all.
>>
>> On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
>>
>> > 3) We're having a new rule--you may *not* take a continuation from
>> > within an opcode function! This is probably one of those "Well, Duh!"
>> > things but better to have it up front.
>>
>> I see why you say this, but I'm not sure it's necessarily a good idea.
>> There are a few languages which rely on continuations within functions
>> (Prolog is the one that springs to mind, but there are others), and
>> without it, the generated code might get unnecessarily bloated.
>
>That wasn't my understanding. "opcode function" to me means the
>internal implementation of a single opcode.
>
>Assuming I am correct, I still don't quite get what the restriction
>is. Is this so that the interpreter is holding the whip at the moment
>stacks need to be juggled? What does this allow and disallow for
>extensions (eg an extension that defines its own opcode?) And what
>does this gain over an API entry to tell the interpreter that you're
>taking a continuation?
I'm not willing to guarantee the interpreter will be in a
sufficiently coherent state, nor that that state can be completely
reconstructed, if we're inside an opcode function when we take a
continuation. It may turn out that I'm excessively worried and that
this won't be a problem, but I'd rather make it a limitation now and
lift it later.
The fact that we might be calling into parrot code from C code in the
opcode function adds to the potential complication here, as we can't
(or at least aren't going to) restore the machine stack and state,
just Parrot's. We can't, then, completely set things up if we take a
continuation that may potentially cross a parrot->C or C->parrot
boundary.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
