|Re:  operator|
Message #12 Posted by Oliver Unter Ecker on 4 Apr 2011, 8:16 p.m.,
in response to message #11 by David Hayden
The overall structure of both cases is
In case A, "something" is RPL.
In case B, "something" is an algebraic expression without quotes.
Each case gives two examples.
I'm getting an "invalid syntax" error if I try to place brackets inside an expression, so 'partitions[pents[k] + 2]' does not work for me (on an HP-49).
Maybe you mean 'partitions(pents(k) + 2)'?
Yes, case B
partitions[pents[k] + 2]
would indeed be equivalent to
'partitions(pents(k) + 2)' EVAL
Thanks for pointing this out. This should make the syntax look friendlier in RPL eyes. I know the lack of quotes may be weird. But the proposed syntax is equivalent to the one in C-like languages.
(Conversely, the expression syntax, what with having "()"s, needing quotes, and an EVAL, is probably very weird from the point of view of most other languages.)
\<< [1 2 3] \-> x \<< 1. 1000. START 'x(1)' EVAL DROP NEXT \>>
runs 6.5x slower than this
\<< [1 2 3] \-> x \<< 1. 1000. START x 1 GET DROP NEXT \>>
So, using expressions instead of GET for array access seems unfeasible. But, again, thank you for pointing out that my proposed syntax B looks almost like the whole thing wrapped in an expression.
> partitions 
This one is easy. The proposed operators are "fused": they *must* be connected to the name of a local. No white-space inbetween allowed. So, your example has the regular meaning.
would be the new thing.
If you try to enter "partitions" on an HP-calc you get "partitions [ 1 ]" on the stack, so that wouldn't work. But, then, RPL+ is not meant to (or, rather, cannot) be retro-fitted to existing HP calcs.
Thanks for feeding in!
Edited: 5 Apr 2011, 6:13 a.m.