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 guess I just don't have enough of a mental model of how parrot will implement continuations to understand this. Is this similar to the analogous current situation, where opcodes can't muck with the program counter without using one of the funky 'goto POP()' family of macros?
