DB48X: HP48-like RPL implementation for DM42

[FLISZT]

(…) Neither WinDev nor FenDev?

(07-18-2023 08:06 AM)c3d Wrote:  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.

Not Wrong!
Another point: I didn't get very well what you meant with "rest" notation in your previous post. Now it's clear. Nice improvement!

(07-18-2023 08:06 AM)c3d Wrote:  

Code:


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

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

I suppose the + operator could be replaced by any command or function (as long as it makes sense).

About possible developments on the FOR loop, things like (Python) in the following examples may be interesting too.

Code:


animals = ["albatross", "bee", "cat"]
for x in animals:
   print(x)

result:

albatros
bee
cat

Code:


for x in "bee":
   print(x)

result:

b
e
e

It's possible that similar ideas have already been developed in https://www.hpcalc.org/details/7971.
I'm far from knowing all the functions by heart.

(07-18-2023 08:06 AM)c3d Wrote:  Otherwise, the difference with this

Quote:

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.

In this previous example, I used a global variable for a single reason: time saving! (in typing)

But I could have written this as well:

Code:


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

Anyway, it's true that…

Code:

« → { x y } « x x * y y * + »

… is a simpler writing and the idea of the "rest"…

Code:

« → { x y z… } « x y z » »

… finishes the job, if i can say so.

A question about your idea of a new construct:
- would it be possible, after having created (e.g.) my_Structure, to create (e.g.) Struct_1, Struct_2 … with this new template?

Asked differently (with your example):

Code:

 
(defstruct book 
   title 
   author 
   subject 
   book-id 
)

… could this template be reused by any books? (say to manage a library…)

About the idea of managing a (sequential) file, I mentioned the SD card reader (or its lack) because this could have been a "portable" and a "all-in-on solution".
But an "at-home solution" suits, at least for me.