Re: The new 39GII and RPN?: Please read and comment. Message #19 Posted by Oliver Unter Ecker on 25 July 2012, 10:12 a.m., in response to message #1 by Pal G.
No language can be simpler than keystroke recording.
RPL is keystroke recording for an RPN machine, plus some optional stuff: control structures and local variables, mainly.
I consider some stuff broken in the latest RPL by HP:
- local variable definition and re-assignment (way unintuitive)
- lack of immediate algebraic expressions
Fix those two things and RPL is as readable a language as BASIC *and* it retains the goodies that come with it being the natural language: implied transport of inputs and outputs (this is huge), concept of retained algebraic expressions, concept of functions as data, 1:1 mapping to RPN operation, etc.
I also observe that there's one thing that commonly makes RPL hard to read: the use of stack operations.
However, after you fixed local variables, you basically don't need them anymore. (Their use is not mandated by the language.)
In summary: for an RPN-operated machine, RPL can be the perfect language. Just modernize it.
Example of "fixed" RPL:
<< =n
sum=0
1 n FOR i
sum=sum+i
IF sum>(n^2/log(10)) THEN BREAK END
NEXT
sum
>>
Anything not "readable"?
Examples of somewhat advanced use of enhanced RPL:
<< 'x^2+5' sqrt sin >> yields 'sin(sqrt(x^2+5))'
<< 1..4 'x' peval >> yields 'x^3+2*x^2+3*x^1+4'
<< 1..10 { sqrt isInt } filter >> yields [ 1 4 9 ]
<< 105..108 {split ! total} {recurse} doUntil >> yields [169 169 363601 169] [12 6 8 33]
It's okay to abandon RPN and RPL. (Though it would strike me as wrong.) But I don't see the point of bringing back one without the other.
It's also okay to have a BASIC-like language. But it's not inspiring. If you break with tradition and backwards compatibility, why don't you pick up a language that is spoken by millions and which becomes a worthwhile investment for anyone deciding to learn it? It's ok to have a library, but yet another unremarkable language?
Edited: 25 July 2012, 10:52 a.m.
|