newRPL: Named subroutines proposal

[Han]

(10-14-2015 04:43 PM)Claudio L. Wrote:  DEFINE is not implemented yet, but will be implemented (but it doesn't count as an improvement to RPL, it has been there forever).
LDEFINE would be a nice addition, and it will definitely be added.

Regarding flag -3: here you have another perfect example why I dislike commands that depend on system flags. DEFINE works best when defining functions, and in that case, it works regardless of the flag, but if you define only a variable, it wants to evaluate the expression first and fails. Doesn't make much sense to me, I'd rather have DEFINE to define it as the expression and perhaps NUMDEFINE if I want to run ->NUM before.

At some point we have to realize that system flags are a must. Some things are black and white so that a system flag will be either permanently set for some and cleared for others (e.g. how complex numbers are displayed -- as (a,b) or a+bi). The issue here, though, really isn't about system flags but how we want the system to handle symbolic objects. The question of whether symbols should be resolved prior to executing the command is the very issue that was a big headache even as far back as the HP48 (resolved slightly via flag -3) and is really bad in the HP Prime. Should inputs be parsed so that all symbols are resolved prior to passing to a command? Or should the command leave some/all of the symbols as they are? To suggest that we have two versions of the same command for each command that handles symbolic input would be beyond crazy, in my humble opinion. There are far to many commands as it is, even for just the HP48.