RPL+



#13

This does not relate to HPs, but to an RPL platform being built:

I think that RPL, the language, can be improved.

I've started to implement a few strictly optional language features that I think make for a better language.

The result is called "RPL+".

I just posted another round of planned features here.

These are pretty drastic, yet I hope they will do good.

Is code like this

\<< =n
0 'n>295' {R\->I} IFT =zero
n mkpents =pents
[0 1 1 0] =signs
{1} =partitions
1 n FOR j
zero @ running sum
1 =k
WHILE
pents[k]
j \=<
REPEAT
partitions[pents[k] j -]
signs[k 4 MOD] {+} {-} IFTE
++k
END
partitions push @ add to partitions
NEXT
partitions[n]
\>>
recognizable to you as RPL?

Would you like to write code like this?

Or do you think RPL should not be changed?

I'd love some input.

Edited: 3 Apr 2011, 12:13 p.m.


#14

Do you have an emulator for RPL+???

A few years ago I implemented RPN2 (an extension to RPN) using Excel. The Excel interface helped type in and run RPN2 programs which supported a whole variety of registers (stack, multiple Alpha registers, multiple array indexing registers), strings, matrices, and flags. I presented RPN2 in HHC2009 (i believe).

The point I am making is the having an emulator allows you to breath life into your concepts.

Namir


#15

Namir,

RPN2? That sounds cool. (I will confess to you, though, that I barely know RPN...)

>Do you have an emulator for RPL+???

Well. I'm not re-purposing hardware (my hat's off to everyone involved in the WP34s project, btw; it's beautiful), so I don't need an emulator. I'm building the real thing.

In the post I referred to, what is not flagged as "(planned)" already exists. And it's out in the wild, actually. Today, there're many thousands of RPL+ calculators (really: apps; currently ND0 and ND1) in the hands of users. So, RPL+ is real.

(Caveat: app buyers are not like calculator buyers. Most of my users don't know what RPL is, and, I suspect, don't use it. But then, 50g language capability and one-tap downloading of code only appeared in an update a month ago.)

What I'm proposing today, I may implement today. And you may download it in two weeks. (The framework that enables me to do that I built over the course of two years.)

#16

Namir,

I don't want to be annoying, but let me tell you that you *could* implement your RPN2 for MorphEngine calculators (the two mentioned before for iOS, but more are in the pipeline, for more OSes; see the road-map).

Either in JavaScript. Using or not using the math and type functionality that is provided by MorphEngine (which is much easier to use than you'd think; essentially, if you know your calculator command-set, you know how to use it after 20 minutes of reading documentation).

Or in RPL. (Is there possibly even something like an RPN emulator implemented in RPL? Should be possible.)

You don't need a development environment. You can do this on the device! (In either language.) (Though, if you have an iPad, you may want to wait for CalcPad (another MorphEngine calc) for a larger editing window.)

You could also develop on a desktop, in JavaScript, and transfer files to run on the device. Setting up a custom server is described in the ND1 reference docs and makes this a one-tap, one-second affair.

If you have a stand-alone JavaScript implementation, developed on a desktop, it takes very little time (probably minutes!) to adapt to MorphEngine, and make it run in the calculator. You could then make it available to all users as a (free) shared folder download. There's a concept of an "extension" and your language could be permanently installed in all calculators of users who press your Install button. It will then be as if the calculator had RPN2 built-in!

If you'd like any of this, I'd be happy to point you the right way and lend some support.


#17

The Excel interface allowed me to view a lot of information simultaneously. Behind the RPN's functions and operation stands thousands of lines of VBA code.

The main goal for RPN2 is to provide structured or modular programming that allows the development of reusable code where one can not worry about clashing register number/names and label names. RPN2 supports modules and each module define a scope for its memory registers and labels.

Anyway, this project of mine is not active. I may add a few small features to enhance decision-making, but there is no rush now.

Namir


#18

Sounds like a really nice project. Love the idea of using Excel as emulator.

Cheers.


#19

Click here to go to my web page and click on HHC2009 RPN2 to download the file RPN2.ZIP.

Edited: 4 Apr 2011, 8:02 a.m.


#20

Hi Namir,

I didn't know you were a prolific writer, and a language whiz.

Thanks for the link. I started to peruse the RPN2 material and am well impressed. Also, I found the root finding articles interesting and may come back to it (my project is in dire need of a capable solver).

Your R "tutorial" is a book! (But you know that...)

It's a pity your RPN2 project's not active. You put a lot of work into that! (It looks really good to me.)

Edited: 4 Apr 2011, 9:38 a.m.


#21

Oliver,

Thank you for your most kind compliments.

I am very glad that the R tutorials attracted your attention. I agree, they can be a book.

Regards,

Namir

#22

Ok. I know I want the array access operator "[]".

But which one of the following two would you choose:

A

                 |   syntax   |
v v v v
ex1 partitions[pents[k] j -]
ex2 signs[k 4 MOD]
^ ^
| local | any RPL

or

B

ex1    partitions[pents[k] - j]
ex2 signs[MOD(k, 4)]
^ ^
| local | an expression (w/o quotes)

?

Note, B makes array access look identical to a C-like language.

Is this too scary for the RPL mind? Think of it as replacing

signs 'MOD(k, 4)' EVAL 1 + GET

To me "signs[MOD(k, 4)]" reads better. (And the comfort doesn't come at a price. Quite the opposite. It's way faster to run.)

Edited: 4 Apr 2011, 3:01 a.m.


#23

Oliver,

I think it's really a question of what syntax will you use for an expression. In both cases, the general syntax appears to be

partitions[ any expression ]
example: partitions[pents[k] + 2]

Note that HP solved this by inventing the algebraic object, so in RPL it might be

'partitions[pents[k] + 2]'

But I'm not sure how you'd distinguish between an array reference and an object followed by a single entry array. For example, is

partitions [1]
a reference to an element in partitions, or does it put the value of partitions on the stack, followed by the array [1]?

Dave


#24

David,

The overall structure of both cases is

    array[something]
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.)

Unsurprisingly, this

\<< [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 \>>
on Emu-48/HP-49.

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 [1]

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.
Only

   partitions[1]
would be the new thing.

If you try to enter "partitions[1]" 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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Writing RPL programs on OS X Sean Freeman 18 2,336 11-30-2013, 03:59 PM
Last Post: Sean Freeman
  48G vs 49G+ User RPL Speed Comparison John Colvin 7 1,073 11-16-2013, 10:07 PM
Last Post: Han
  RPL 32 David Hayden 4 888 11-11-2013, 11:34 AM
Last Post: David Hayden
  HHC / HP Museum Programming Contest for RPN and RPL machines Gene Wright 18 2,229 09-22-2013, 09:39 AM
Last Post: Miguel Toro
  RPL long vs. short names peacecalc 5 887 10-30-2012, 01:25 PM
Last Post: peacecalc
  Mini-challenge: HHC2012 RPL programming contest with larger input David Hayden 14 1,740 10-05-2012, 10:36 PM
Last Post: David Hayden
  HHC 2012 RPL Programming Contest Gene Wright 33 3,235 09-27-2012, 01:57 AM
Last Post: Werner
  HHC 2012 programming contests coming soon (RPN and RPL) Gene Wright 9 1,235 09-21-2012, 03:38 PM
Last Post: Paul Dale
  RPL prog for Fibonacci on HP 48G needs minor modification. help. wildpig 68 5,852 07-09-2012, 09:38 AM
Last Post: Gilles Carpentier
  RPL/2 under HP-UX Martin Paech 2 507 04-21-2012, 07:36 AM
Last Post: David Hayden

Forum Jump: