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

[JoJo1973]

(08-24-2021 03:55 PM)Claudio L. Wrote:  Unofficial ROMs updated to 1497.

Time to test the new FORUP and FORDN commands!
Other bugs in ATAN, LN should be fixed now, please test.

I'd like to submit my entry for the Suggested Command of the Month© contest... an implementation of the Check&Dispatch structure!

As we all know, all RPL variants encourage a bottom-up approach to programming and this means that usually there is a main program that crunches the input data to ensure it is valid before calling the actual subroutines.

The problem is that this task can become incredibly boring and convoluted, especially if the objective is to write a library. The simple task to check for three arguments on the stack being a list and two positive integers robs the programming of half the fun!

To ease the burden nothing beats the elegance of SystemRPL's Ck&Dispatch structure which I propose to implement in NewRPL as follows:

Code:


CHECK
    { arglist1 } THEN
        ...
    END
    { arglist2 } THEN
        ...
    END
    .
    .
    .
    ELSE
        ...
    END
END

Each arglist is a list of real numbers, where positive ones are compared against the output of TYPE (if integer) / TYPEE (if they have fractional part), negative one against the output of VTYPE/VTYPEE and 0's are just placeholders meaning "any type".

The check mechanism would retain SystemRPL behaviour wrt tagged objects: the arguments are checked twice; in the first pass tagged objects trigger a match only if arglist explicitly requires a tagged object; in the second pass the tags are stripped and the payload is checked to trigger a match.

It's not mandatory for the arglists to have the same length: the first valid match is dispatched.

The ELSE clause is optional: the default behaviour is "Bad Argument Count" in case of total mismatch or "Bad Argument Type" if at least there is a count match.

Some arglist examples:

Code:


{ } THEN 'SUB0' XEQ END                   @ No arguments: trivial but legal

{ 0 0 0 } THEN 'SUB1' XEQ END             @ Three items on the stack, no matter their type

{ 62 10 } THEN 'SUB2' XEQ END             @ A list and a real number (any kind of real: integer, not integer, exact, approximate, binary, hexadecimal...)

{ 52 10.22 10.33 } THEN 'SUB3' XEQ END    @ A matrix and two real numbers, an approx octal and an exact hex

{ -62 0 10.12 } THEN 'SUB4' XEQ END       @ A variable containing a list, a generic object
                                          @ and a real number, integer and exact

Of course the CHECK..END structure isn't necessarily used to call other programs:

Code:


«
  CHECK
    { 62 } THEN
      « CHECK { 10.12 } THEN DROP 1 END ELSE DROP 0 END »
      1
      DOLIST
      ΠLIST
    END
    { -62 } THEN
      DUP RCL
      « CHECK { 10.12 } THEN DROP 1 END ELSE DROP 0 END »
      1
      DOLIST
      ΠLIST
    END
  END
»

Returns 1 if the argument is a list (or a variable storing a list) of undetermined size containing integer, exact elements and 0 otherwise. I'm assuming here that CHECK doesn't 'consume' the stack.

The arglist concept could also be useful during library creation: at the moment the programmer must provide the number of parameters; instead it could provide a "list of arglists" albeit with the limitation that they must have the same size to comply with NewRPL programming practices.

The beauty is also that as long as sub-type identification becomes smarter, CHECK..END becomes more powerful.

What do you think?