newRPL: Alpha demo 0.9 released [UPDATED 2017-10-25]

[Claudio L.]

(08-10-2017 12:45 AM)The Shadow Wrote:  I assume that you can only have 8 levels of SPUSH'd stacks? That it in fact uses the same storage as the UNDO feature? Are those stacks stored anywhere the user can get at (other than using SPUSH and SPOP, I mean!)

I can see lots of uses for these already!

They are in fact unlimited up to available memory. The 8 limit is the stack front-end purging older snapshots when there's more than 8, but inside your own program you can create as many as needed. The idea is your program should destroy them before returning, so only the actual user interaction with the stack remains in the UNDO list (unless of course you do this on purpose for whatever reason). The UNDO feature in the left cursor does nothing but revert the stack to one of the previous snapshots (without purging it, so you can REDO), and every time you press a menu or run a program it does SPUSH internally to create one, and checks if there's more than 8 purges the oldest one.
Stack snapshots prevent objects from being garbage collected, so it's not a good idea to abuse this by creating many snapshots.

I'm thinking the internal API could be exposed further, with commands like:

n SPICK --> Overwrite the stack with the contents of snapshot 'n'. SPOP is therefore << 1 SPICK SDROP >>
n level SPICKN --> Copy the object from snapshot 'n', level 'level' into the current stack level 1
n SDEPTH --> Get the depth of a snapshot 'n'
SCOUNT --> Get total number of snapshots
n SPURGE --> Destroy the snapshot 'n'

(08-10-2017 12:45 AM)The Shadow Wrote:  What commands do you have in mind?

I was looking into porting David's new list functions library as the first newRPL external library written in RPL, but it's just an idea in the planning stages for now. First I need to implement user installable libraries.

(08-10-2017 12:45 AM)The Shadow Wrote:  I see. For some reason I assumed they took arguments, like HIDEVARS and UNHIDEVARS. This makes more sense.

They affect all locals up to the point where HIDELOCALS is included (hence no arguments needed). Any local defined after HIDELOCALS will still be visible. It's most needed when you are preparing to execute user code, like evaluating a user supplied equation from within your program. You don't want that equation to accidentally pick the value of one of your local variables, so you need to hide them, call the user code, then un-hide them.