At 4:26 PM -0400 6/30/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
... I'd also like to be able to manipulate the stacks in a context,
pushing things on them, changing values on them, and generally
messin
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote:
>>Dan Sugalski wrote:
>>> ... I'd also like to be able to manipulate the stacks in a context,
>>> pushing things on them, changing values on them, and generally
>>> messing about with the things, so I'm al
At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
... I'd also like to be able to manipulate the stacks in a context,
pushing things on them, changing values on them, and generally
messing about with the things, so I'm all for it.
Do you have some examples for a usage of such
Dan Sugalski wrote:
[ update continuation PMC at call time ]
Here are some possibilities to achieve this:
- invokecc (this is slow)
- a new opcode e.g. C (update continuation ctx)
- toss invokecc's current functionality and use this opcode to update
the context and call the sub.
I like option 2.
At 2:43 PM +0200 6/28/03, Leopold Toetsch wrote:
In the meantime interpreter->warns has moved to the context
structure and gets now restored for CPS subroutine calls.
But there is a slight problem (as well as with e.g. pad_stacks)
When we have:
warningson 1
newsub .Sub, .Continuation, _func,
In the meantime interpreter->warns has moved to the context structure
and gets now restored for CPS subroutine calls.
But there is a slight problem (as well as with e.g. pad_stacks)
When we have:
warningson 1
newsub .Sub, .Continuation, _func, _ret
...
invoke
and _func turns warnings off,
