newRPL documentation - Part I available
|
03-26-2015, 03:58 PM
Post: #8
|
|||
|
|||
RE: newRPL documentation - Part I available
(03-24-2015 07:49 PM)Gjermund Skailand Wrote: Hi. 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 >> 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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)