Threaded Mode | Linear Mode

BruceH · 01-02-2014, 07:49 PM

(01-01-2014 08:29 PM)Claudio L. Wrote: The big question is if it can ever work well enough to be useful.

It depends on your definition of 'useful'. If you think it means achieving binary compatibility with existing code uploaded to hpcalc.org then no, it could never be useful. If like me, you want a calculator that makes it faster to *write* programs and solve problems, rather than just *run* code faster, then a new userRPL could be very useful indeed.

I think that:

a cleanly re-implemented userRPL in ARM rather than Saturn will be very fast, negating the main reason for using sysRPL
with the benefit of hindsight and years of community experience, there are run-time and compile-time optimisations that can be applied to userRPL to make it faster still. (Dave and I have already exchanged ideas on this by email)
starting afresh with a blank canvas allows more modern features to be added to userRPL to make it simpler to write programs[1] and easier to add complexity when necessary[2].

Imagine you're trying to solve a problem and are 'playing around with numbers' on the stack. Suddenly you find you've got the right answer. Instead of putting the calc into 'programming mode' and then attempting to write a program that re-creates what you just did, imagine being able to review the keystrokes you entered and the stack (and memory values) as they were at the time. You 'scroll' back up through your work and 'cut' the relevant bit into a function or a program. The calc 'knows' how many arguments you used from the stack and creates an appropriate function definition. (Or it's RPL/RPN and so doesn't matter.) You then review the newly created program and remove any redundant steps that were in your original working but not required for the final version, since removing is always easier than writing.
The above is great for 'informal' programs. For more considered programs, a language like new userRPL can be used. Given [1] above, the approach to defining the feature set for userRPL can be changed because it no longer has to be a one-size fits all language. I have my personal preferences as to what I would like to see in there - but rather than make this post stray too far from its original point, I will limit myself to saying that binary (or even just source) compatibility with existing sysRPL is at the very bottom of my list. ;-)