DB48X: HP48-like RPL implementation for DM42

[c3d]

(07-17-2023 11:41 PM)FLISZT Wrote:  More precisely, I was thinking of backward compatibility... if possible.

That was the way I read it.

Quote:

(07-17-2023 07:13 PM)c3d Wrote:  For example, consider the `Dup` function. In DB48X, this can also be spelled `Duplicate`. There are preferences that let you display (and see it in the editor) as either `dup`, `DUP`, `Dup` or `Duplicate`. On input, you can spell it either way, as well as all case variants, e.g. `DUPLiCATE`.

Interesting, but it makes a big difference with RPL. As you know, on an hp-28 or hp-50, DUP is a command, whereas dup, Dup, dUP (...) will be considered as different variables.

Good point. I opened an issue to remember that. However, note that the space of reserved keywords kept changing with each revision of RPL, so there is no real guarantee about which names you can use in your program across RPL implementations (only within one specific implementation).

The rationale for accepting multiple spelling is because the usage model for the DM42 is in my opinion quite different from the traditional usage model on the HP48 due to the presence of a standard USB port and a disk mode. To me, this means that I must be able to accept programs typed on the calculator's keyboard (typically uppercase) as well as from a computer (where I DON'T WANT TO SHOUT ALL THE TIME :-).

This is why the state file is in clear text, not in binary format like on the stock DM42 firmware.

Quote:In my opinion << Duplicate >> isn't very useful because it's too long. But I do understand that this is just an example.

This is exactly why there is a preference for that.

I happen to like the long spelling. Not necessarily for DUP, which is common enough, but for functions like RNRM, RRK, RSBERR, SIDENS or TDELTA. If you can remember what they do without looking up the manual, congrats. I cannot, so I'd much rather have them display as RowNorm, RosenbrockErrorEstimate, RosenbrockRungeKuttaSolver, SiliconDensity and TemperatureDelta and save myself a trip to the manual. Hopefully, the built-in help will also make it easier to remember what these functions do and how to use them.

Quote:It reminds me of WinDev (French Software Engineering Workshop) whose programming language can use English or French keywords. I don't know much more...

Not sure I appreciate the comparison ;-)

Quote:

(07-17-2023 07:13 PM)c3d Wrote:  << Lambdas are already a part of standard RPL. \lambdax(x+1) is written « → x 'x+1' » in RPL. You do not need to name that object.

Yes, that's right!
When I talked about anonymous functions, I was thinking of something simpler in terms of syntax (no chevrons). But it's true that algebraic writing is, in this case, a very good alternative that I rarely think of. Nevertheless, you need to have one variable (or more).
Something like this (Python)

Code:

lambda : print('Hello World')

is not possible... but perhaps not very useful either.
À oublier…

But again, lambdas are nothing but functions or programs without a name, which is exactly what RPL equations or program objects are. Your "Hello World" equivalent would be something like:

Code:


« "Hello World" 1 DISP »

Quote:

(07-17-2023 07:13 PM)c3d Wrote:  What could integrate well into RPL is an extension of the current local syntax to split lists into components. Something like « → { x y } « x x * y y * + » » would turn { 1 2 } into 5. The same could make sense for arrays as well, e.g. « → [ x y z ] 'sqrt(sq(x)+sq(y)+sq(z))' » would compute the norm of a 3-vector.

Interesting, but it requires a function capable of accurately processing the number of elements contained in the list. Or ?? https://www.hpmuseum.org/forum/thread-12902.html

This is the intent of the "rest" notation. This would allow you to recurse efficiently. Another thing I am considering is a "list processing" variant of `for`, e.g.

Code:


'X' { 1 2 3 45 } for i i + next

would give you X+1+2+3+45

Quote:Otherwise, the difference with this

Code:

<< 
{7 8} 'L' STO
'L(1)'  
'L(2)' 
→ x y ' x * x + y * y ' 
EVAL
>>

won't be that big.

It would be in terms of efficiency. A global storage like you L does not just pollute the user-visible variable space, it is very slow (relatively speaking) both in classical RPL and in db48x. Global variables are stored in one place which requires to (at least potentially) move many other objects when you change their values. By contrast, local variables use the same kind of fast temporary storage as the stack.

Quote: But for an array... yes!
On the other hand, if you do it for an array (or vector), why not do it for a list… or even a string.

(07-17-2023 07:13 PM)c3d Wrote:  Structs also exist, they are called "lists". However, RPL is a dynamically typed language, and I do not plan on adding statically typed data (it would really not help much in terms of speed or size given how things are implemented today).

I don't know much about the underside of RPL (sysRPL). It's quite possible that adding a static data structure is very difficult.
In LISP (very list-oriented... ), it's possible to do this:

Code:

(defstruct book 
   title 
   author 
   subject 
   book-id 
)

https://www.tutorialspoint.com/lisp/lisp_structures.htm

I'm still convinced that it would be interesting to be able to do something similar, provided it's feasible, of course.

This was exactly the idea of my proposed new construct. You would use a list to pass the data around, and extract fields with

Code:


« → { title author subject bookid }
    «
        title ... 
    »
»

It might be useful to have something that builds a tagged list. For example

Code:


   "Informagie"
   "Christophe de Dinechin"
   "How dinosaurs save humanity with the help of a videogame AI"
   "https://www.amazon.fr/dp/B07Z4XJ4Y9"
    { title author subject bookid } →TaggedList

(a clear plug for a fascinating book) would produce this list:

Code:


    {
        title:"Informagie"
        author:"Christophe de Dinechin"
        subject:"How dinosaurs save humanity with the help of a videogame AI"
        bookid:"https://www.amazon.fr/dp/B07Z4XJ4Y9"
    }

I could even call it →Struct instead of →TaggedList.

Quote:Another thing I'd thought of was the possibility of managing a (sequential) file… but there's no SD card reader in DM42 nor in DM32!

But there is a local FAT filesystem which is easily accessible over USB. So file access make sense. I'm still thinking about how to expose that functionality. Today, the only feature that is implemented lets you save the calculator state to disk, and is mapped to double-shift EXIT.

Quote:Last but not least, I'm sure there are possibilities in https://www.hpcalc.org/details/7971 that could inspire you, if they haven't already.

Thanks for the insights.