2023-05-23 18:30:00 <KipIngram   > You know, an easy "starting point" for building a system would be just to write KEY, EMIT, and JUMP primitives and set the thing off running a BEGIN KEY EMIT AGAIN definition.
2023-05-23 18:30:09 <KipIngram   > Then you could "grow it" one little step at a time.
2023-05-23 18:30:22 <KipIngram   > That's something that could be put together in a really short time.
2023-05-23 18:32:27 <KipIngram   > I complained last weekend that using >r and r> interferes with ability to factor.  I thought about a separate stack for temporary data storage like that - apart from the return stack.
2023-05-23 18:32:52 <KipIngram   > I realized last night I've already got one.  I don't use the standard stack for anything.
2023-05-23 18:33:35 <KipIngram   > >s s> s@ are trivial primitives.  And, since that stack isn't in my main system image, it's an ideal place to stash that one return address I need to hang onto when I'm restoring a snapshot on error recovery.
2023-05-23 18:34:01 <KipIngram   > It's also usable from the interpreter, which >r r> are not.
2023-05-23 18:34:41 <KipIngram   > Though, if you change the EXISTING content of that stack and then throw an error, those changes will persist.  The stack POINTER gets restored, but if you overwrite data that was in that stack you can't get it back.
2023-05-23 18:35:13 <KipIngram   > But it seems like an awfully  nice replacement for >r r> in temporary data storage cases, since it doesn't disrupt factoring.
2023-05-23 18:35:58 <KipIngram   > I.e., if you only USE it the way you'd use >r r>, then you don't encounter that imperfection.
2023-05-23 18:54:17 <KipIngram   > Anyway, given how easy those primitives are, I'm adding it.
2023-05-23 18:54:26 <KipIngram   > Too convenient and too "cheap" to pass on.
2023-05-23 18:56:55 <KipIngram   > I stuck those in and got rid of the other primitives I'd written for stashing that return address on unsnap (in a register) - those were of no other use so I'm glad to be rid of them.