Stack mark ops & such.
Dan Sugalski
marks, and suchlike things into the core. This is everyone's chance
to tell me how bad an idea that is. :)
First important note--Marks can be popped to either as an error (for
example when unwinding because of an exception) or as normal (for
regular pops on scope leave and such). This is to facilitate rollback
activities on error and suchlike things.
pushmark: push a marker on the control stack. Does nothing else.
popmark: Pop a marker from the control stack.
popmarkerror: Pop to a marker, passing an error status to everything
being popped.
mark[ispnuf]: mark where the int, string, pmc, number, user, or
fastint stacks are. When popped, they go back there.
rememberval: Pushes a pointer and a value. When popped, the value is
put back in the pointer
tempval: Like rememberval, only it only gets undone on error
This all goes on the control stack, FWIW. Dunno what (if anything)
we'll do special for the user stack.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jerome Vouillon
> Okay, I'm about half a step from putting pushmark, popmark, stack
> marks, and suchlike things into the core. This is everyone's chance
> to tell me how bad an idea that is. :)
How is this going to interact with continuations and coroutines?
For instance, what is the example below supposed to print? And how
are we going to implement this?
coroutine foo () {
do {
temp $x = 2;
print "$x\n";
yield;
print "$x\n";
}
print "$x\n";
yield;
}
$x = 0;
print "$x\n";
do {
temp $x = 1;
print "$x\n";
foo (); # This executes foo up to the first yield
print "$x\n";
}
foo (); # This executes foo from the first yield to the second one
print "$x\n";
-- Jerome
Dan Sugalski
>On Mon, Aug 05, 2002 at 03:52:11AM -0400, Dan Sugalski wrote:
>> Okay, I'm about half a step from putting pushmark, popmark, stack
>> marks, and suchlike things into the core. This is everyone's chance
>> to tell me how bad an idea that is. :)
>
>How is this going to interact with continuations and coroutines?
Interestingly. :)
Yielding out of a coroutine doesn't unwind anything, so there's no
problem there. We only unwind on a return or uncaught exception.
Continuations... those are more interesting. Potentially we can
unwind the same chunk of stack multiple times. Which is a good point,
and I'm glad you brought it up--means I need to undo one of the ops.
Thanks!
Melvin Smith
At 10:43 AM +0200 8/5/02, Jerome Vouillon wrote:
>>On Mon, Aug 05, 2002 at 03:52:11AM -0400, Dan Sugalski wrote:
>>How is this going to interact with continuations and coroutines?
>Continuations... those are more interesting. Potentially we can
>unwind the same chunk of stack multiple times. Which is a good point,
>and I'm glad you brought it up--means I need to undo one of the ops.
But currently each continuation gets its own copy anyway, whether
it is explicit or carries the COW flag, so is there actually any
problem here?
-Melvin Smith
IBM :: Atlanta Innovation Center
mel...@us.ibm.com :: 770-835-6984
Dan Sugalski
>At 10:43 AM +0200 8/5/02, Jerome Vouillon wrote:
>>>On Mon, Aug 05, 2002 at 03:52:11AM -0400, Dan Sugalski wrote:
>>>How is this going to interact with continuations and coroutines?
>
>>Continuations... those are more interesting. Potentially we can
>>unwind the same chunk of stack multiple times. Which is a good point,
>>and I'm glad you brought it up--means I need to undo one of the ops.
>
>But currently each continuation gets its own copy anyway, whether
>it is explicit or carries the COW flag, so is there actually any
>problem here?
The only issue is potentially popping something with an active pop
function more than once. Though if we document that, I don't know
that it's a big problem.
Jerome Vouillon
> At 10:43 AM +0200 8/5/02, Jerome Vouillon wrote:
> >How is this going to interact with continuations and coroutines?
>
> problem there. We only unwind on a return or uncaught exception.
Have you looked at my example. It seems to me that the last value of
$x will be 1 (the value restored by the coroutine), while we would
probably expect it to be 0 (the initial value).
-- Jerome
Dan Sugalski
Since $x is a global, that should be:
0
1
2
1
2
0
0
Through the joys of nested globals namespaces. :)
Jerome Vouillon
> At 12:27 AM +0200 8/6/02, Jerome Vouillon wrote:
> >Have you looked at my example. It seems to me that the last value of
> >$x will be 1 (the value restored by the coroutine), while we would
> >probably expect it to be 0 (the initial value).
>
> Since $x is a global, that should be:
>
> 0
> 1
> 2
> 1
> 2
> 0
> 0
>
> Through the joys of nested globals namespaces. :)
This can make sense for globals. But if you replace all occurences
of $x by @x[0], will you get the same result? If so, how do you
implement this? (And if not, how are you going to explain the
difference to the user?)
-- Jerome