newRPL - Updated to build 1510 [official build remains at 1487]

[Claudio L.]

(08-09-2021 07:25 PM)Wes Loewer Wrote:  Okay, will do. The following aren't bugs but rather more design decision questions.

I was relieved to see that ADD and + are reversed for list processing. This was a longstanding shortcoming in the 50g and its ancestors. (For those unfamiliar with this issue, see https://groups.google.com/g/comp.sys.hp4...rvP3IHIdEJ from 10+ years ago.)
I wonder though if using a word like CONCAT might be better than ADD as it is more descriptive. Perhaps you could make CONCAT a synonym but keep ADD for historical reasons.

I don't oppose to having an alias, but if it has more than 3 letters it's harder to type, so I would personally never use it!

(08-09-2021 07:25 PM)Wes Loewer Wrote:  Another quirk of the 50g that I found annoying when programming was the behavior of the FOR and START loops in that they alway execute at least once, even when the condition would indicated that the loop should not be executed at all.

In other languages that I am familiar with (pascal, c/c++, java, hp ppl), something equivalent to

Code:

 FOR I FROM 5 TO 1 DO PRINT(I) END

would not print anything at all since the exit condition is already met before the loop begins. However, on the 50g, FOR loops are always executed at least once. So instead of something like

Code:

A B FOR I ... NEXT

you'd have to nest it within an IF statement.

Code:

IF A B <= THEN A B FOR I ... NEXT END

which always struck me as a bit of a kludge.

I noticed that newRPL reproduces this behavior. I can understand the pressure to do this to maintain compatibility, but I wondered since you were willing to break compatibility with ADD/+ for a good cause, then maybe you'd be willing to do the same with the FOR and START loops in order to be more logical and more consistent with other languages.

(Are there other languages that execute FOR loops at least once like this?)

Thoughts?

This is a very fundamental behavior of RPL. Breaking + and ADD affects only a few programs and it's a relatively easy fix. Changing the behavior of loops means almost EVERY program would be affected, and they would all need to be rewritten.

So I'd keep FOR the way it is, but I agree with Sylvain nothing prevents creating a new loop structure.
The problem with FOR is because the STEP is not known until you reach that statement, so the check cannot be done at the beginning.
Maybe:

Code:


<start> <end> <step> STEPFOR ... NEXT
<start> <end> <step> STEPFOR ... <step> STEP

This would be exactly like performing an additional STEP instruction before the FOR, which would exit the loop if the limits are in the wrong direction, and enter the loop otherwise (without actually doing the STEP in the counter). This solution could easily be intermixed with the standard FOR NEXT and STEP instructions.

Another completely different direction would be to implement a more generic FOR (C-Style):

Code:


 <<init clause>> <<test clause>> <<increment clause>> STARTFOR ... ENDFOR

In this case, STARTFOR takes 3 arguments. It EVALs the first, then EVALs the test clause before entering the loop, then ENDFOR will EVAL increment clause, then test clause, then restart the loop.

But it becomes very similar to the DO ... UNTIL ... END, or WHILE ... REPEAT ... END loop, so I'm not convinced it's worth adding something like this.