newRPL documentation - Part I available

[Claudio L.]

(03-24-2015 07:49 PM)Gjermund Skailand Wrote:  Hi.

I like your simple style for rpl description and examples.

However, for me it would probably be of interrest to add my own objects and libraries in C. I remember looking at the developer docs a while ago, and found it to be a but too terse and technical for a hobbyist like me (I actually learnt C because I wanted to program the hp50g in hpgcc) and would like to see some small but complete examples.
On a sidenote: I could not see if the for-next loop does the testing before executing the loop. I would consider it an improvement if behavior was changed to test first.
Best regards
Gjermund

You are correct, the developer docs were written in a rush to help my then development team-mates get up to speed with the platform. The docs must be very bad since they never coded a single line... and this is entirely my fault, but rest assured the platform is incredibly flexible.
Everything is in separate .c files (called "libraries" for historic reasons, but they are modules), you can add new object types, new commands and pretty much anything you want is doable just by adding a .c file, registering it with the system and writing one function handler (only one).
The system will call your library handler to compile, decompile, display, evaluate, operate upon, run commands, etc.
That handler interface is what I need to write lots of examples on, etc. The only reason I haven't done so yet is because the API itself is not very stable until all the core classes are implemented. For example I haven't defined yet how the libraries will do "pretty-print" display of custom objects wile still being "hardware independent". Just this week I tried to implement matrices, and realized I'll need additional API to tell the decompiler where to find each element within the object data, since matrices are not like lists where I can just let the decompiler make one pass through all the objects.

Regarding FOR/NEXT, for compatibility reasons, it behaves exactly like classic RPL, with the test being done at the end. The problem is that there's no way of knowing when the FOR loop is executed whether you should or not go in.
For example:

Code:

<< 3 1 FOR I I 3 / NEG STEP >>

When you execute the FOR entering the loop, all you know is that you are going from 3 to 1. If the step is positive or negative is unknown until you reach the STEP word and have the actual value in the stack. Only by executing the loop once you'll know if you are decrementing or incrementing that counter. If the step is positive, I>1 would end the loop, but if the step is negative, I>=1 would continue the loop.
Granted, we'd know the increment is +1 if we use NEXT instead of STEP, but then FOR/NEXT would behave different from FOR/STEP, wouldn't be consistent.