>
> Yeah, this'll happen, and it's an unintended side-effect of the
> changes in Parrot -- the User stack is essentially sub-local. That's
> good for a lot of things, but really, really messes up stack
> languages like Forth.
>
>
> The only real option here is to maintain your own stack and le
Dan Sugalski wrote:
The only real option here is to maintain your own stack and leave its
PMC in one of the registers.
Should we move the user stack out of the interpreter context?
leo
At 4:57 PM -0400 9/18/04, Matt Diephouse wrote:
On Fri, 17 Sep 2004 21:24:35 -0700, Steve Fink <[EMAIL PROTECTED]> wrote:
On Sep-17, Matt Diephouse wrote:
> o Calling subroutines from an eval creates a copy of the user stack,
> so all changes are lost (rendering my Forth code unusable). Is this
On Fri, 17 Sep 2004 21:24:35 -0700, Steve Fink <[EMAIL PROTECTED]> wrote:
> On Sep-17, Matt Diephouse wrote:
> > o Calling subroutines from an eval creates a copy of the user stack,
> > so all changes are lost (rendering my Forth code unusable). Is this
> > behavior correct? If so, how should I go
On Sep-17, Matt Diephouse wrote:
> Having mentally absorbed the forth.pasm code, I thought I'd rewrite it
> in PIR and try to make it a full parrot compiler and, hopefully, a bit
> more approachable. I've already begun on this (see attached file).
> Unfortunately, I've run into a few issues/questio
