Post Reply 
newRPL: Named subroutines proposal
10-15-2015, 01:33 AM
Post: #10
RE: newRPL: Named subroutines proposal
(10-14-2015 06:52 PM)Han Wrote:  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).

And I agree 100%. That's exactly what flags are for. To control certain behaviors and preferences from the user. But should flags be allowed to control the output of commands so extensively as they are?
The constant "suggested" mode changes are annoying, and they only exist to mitigate the frustration of users that would get either wrong results or error messages. Then the large amount of posts in the forum saying things like "I do this and I can't get an answer" and were replied with "set flags -3, -23, -57 and there you go" (flag numbers are made up, BTW).
I don't say we don't need flags, I simply think that 700 commands and 128 flags is too many, there has to be a way to simplify that.

(10-14-2015 06:52 PM)Han Wrote:  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?
I think we are getting to the point. There should be a simple syntax for the user to indicate what he wants.
In newRPL, the trailing dot was used to indicate numbers that want to be operated upon immediately (which I call approximated). This could be extended to commands and variables for example, to try to do what you suggest.
For example 'SIN(X)' would only evaluate X when you EVAL the expression, not when you enter it. But perhaps you could write 'SIN(X.)' to indicate you want X replaced immediately, and you'd see on the stack 'SIN(pi/2)' assuming 'pi/2' is the contents of X, and this could be recursive, if the contents is 'pi./2' then pi would be replaced immediately.
In other words, the trailing dot would work as an abbreviation of EVAL, and you use it whenever you want in your expression.
The opposite is also possible (and perhaps more common): if you want a symbol not evaluated you use some sort of "quote" command or symbol to prevent evaluation, otherwise it gets evaluated. This is more for languages where symbolic computing is very rare, otherwise you'd have "quote" all over your expressions.

(10-14-2015 06:52 PM)Han Wrote:  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.
That's of course an exaggeration, most commands can work around their flag issues, only a few would need to be split. In the case of DEFINE, for example something like the trailing dot explained above would solve the problem completely. The expression itself would ask to be evaluated or not, it is not for the command to decide.
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: newRPL: Named subroutines proposal - Claudio L. - 10-15-2015 01:33 AM



User(s) browsing this thread: 1 Guest(s)