newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Claudio L.]

(01-24-2017 05:50 PM)The Shadow Wrote:  I've been thinking some more about EVAL. It has always been a command that tried to wear way too many hats.

* It replaces variables.

* It simplifies expressions.

* It executes programs.

* It "executes" lists.

* It even makes Julienne French fries!

I get the compatibility argument. But I wonder if it's outweighed by the blessed ability to treat vectors, matrices, and lists in exactly the same way?

In newRPL EVAL is an overloadable operator. Each object can be defined to do whatever it wants on EVAL. If you define an object potatoes, it of course will do french fries.

(01-24-2017 05:50 PM)The Shadow Wrote:  What if EVAL did only the first two things on the list above, and executing things was a new command? I notice there's a new command XEQSECO, which I assume is for executing secondary programs in some sense; what if there were a command XEQ which does for programs and lists what EVAL does now?

The only downside (other than compatibility) that I can see is that there'd be no obvious button to run a program on the stack. Really the only objection I have to EVAL is what it does to lists; maybe it could continue to run programs? Or maybe we map XEQ to where PRG is now and call it good.

There's 3 overloadable operators in newRPL for this task: EVAL, EVAL1 and XEQ. From that point of view, it's not a command that does many things, but an operation defined differently by each object type.
XEQ is a short for Execute, and it's intended to get something done (right now run a program, everything else is just left in the stack untouched).
EVAL does evaluation, mainly anything that contains symbolics does a variable replacement (fully recursive), programs are also executed. The only exception is the list: I disagree with the current behavior of exploding the list, I think it should pass the EVAL to its elements, just like any other unary operator on a list. But it was kept there for compatibility, as I saw code using that to explode lists. I'm in favor to change it, maybe you should start a poll or something.
EVAL1 is the same as eval, but does only one step if possible (in other words, is not fully recursive, does only a single pass).

For example:
'X+1' 'X' STO
'X' EVAL --> 'X+1' in classic RPL
'X+1' EVAL --> Circular reference error in classic RPL, this is not consistent. Why does it try to evaluate 'X+1' ad infinitum, but 'X' just does a single step? In my mind it should be:
'X' EVAL --> Circular reference error (in all cases tries to evaluate recursively replacing everything).
'X+1' EVAL --> Circular reference error

Then EVAL1 comes to rescue:
'X' EVAL1 --> 'X+1'
'X+1' EVAL1 --> 'X+2'

Which allows you to use recursive formulae.

(01-24-2017 05:50 PM)The Shadow Wrote:  P.S. Three totally unrelated things:

1. Shouldn't there be angle commands to 'label number as an angle of the current format, whatever that may be' and 'convert angle to current format'?

They are both automatic operations, a number will be interpreted as an angle in the current format, so there's no need to "convert" from one another. For the same reason, an angle object will be automatically converted to a number in the current angle format before operating with a plain number.
EDIT: However, I already have this task in the bug tracker.

(01-24-2017 05:50 PM)The Shadow Wrote:  2. Is there any way to get a list of units that have been UDEFINE'd? Since they don't show up in directories, and there's no way to add them to the Units menu, I imagine it would be easy to lose track of them.

You can always add them to a custom menu, just use the unit object with a 1_[xxx] in the menu definition, and it will automatically behave the same as in the Units menu (even the 1_ will be hidden).
EDIT: I can probably add ULIST or something like that to do this, so ULIST TMENU would give you that special custom units menu.

(01-24-2017 05:50 PM)The Shadow Wrote:  3. Is there any compelling reason not to use the left and right arrow keys as NXT and PREV?
Or some shifted version, if it's felt important to keep the SWAP function on the right arrow? (I personally almost never use it.)

Yes, when you are in the editor, you still need NXT and PREV, but you need the cursors to move the cursor. All shifted versions are already used in the editor.

(01-24-2017 05:50 PM)The Shadow Wrote:  Oh, and I just noticed:

4. I wiped memory, but once again I'm getting the problem with the DISABLE key.

Sorry, can't reproduce it here. The label only switches a flag on and off, same as all other labels in that menu. I looked and everything looks fine, I don't know what else could it be.