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

[JoJo1973]

(09-08-2021 03:10 PM)Claudio L. Wrote:  Looks nice and clean! But maybe we can reuse the CASE structure with some clever commands and not introduce another complex flow control structure into the language.
On another hand, the CK&Dispatch method almost never worked for me in real life, except for very simple commands.
You end up with situations where 5 or 10 cases are needed for the same basic code, then other 5 or 10 for another, etc.
A very simple example, some code takes 1 argument: can be a real or a complex. Your code works the same whether is a real or complex, all you need is a "numeric". Also you may accept the complex i constant (which has a different type but it's 100% equivalent to (0,1)), so you'll end up with 3 argument list cases for the exact same code. Now let's imagine one that takes 2 of these arguments. Your list cases will need to cover all combinations: real/real, real/complex, real/i, complex/real, complex/complex, complex/i, i/real, i/complex, i/i.
So it explodes into a nightmare really easily. It would be OK if you needed different code for each case, but in most cases you don't.

Well, Ck&Dispatch is probably best suited for Saturn architecture: your 'orthogonal' approach yields more synthetic code so I'm all for it.

Quote:What I find works better for me is to check the arguments one by one, and each argument against a list of valid types, not just one type.
Something like:

Code:


1 { 10 30 55 } ARGCK

In this case, ARGCK takes a stack level and a list of valid types. It will error Bad Argument Type if there's no match, or continue execution if everything is fine. There could also be a version that doesn't error but returns true/false for example, to be used in IF or CASE statements.
In the example above with 2 arguments, you could simply do them in sequence:

Code:


1 { 10 30 55 } ARGCK
2 { 10 30 55 } ARGCK

If it didn't error, you have the right types. Now let's say some cases need special handling, in the example above we may want to convert the constant 'i' into a complex number by doing ->NUM, and perhaps accept other things like a complex number in symbolic form '1+i'.
Let's say we create the ARGCKTF command (ARG ChecK True/False, I'm open to better name suggestions) that doesn't error, we can use IF to simply do ->NUM and try again:

Code:


IF 1 { 55 32 56 } ARGCKTF THEN ->NUM END
1 {10 30 } ARGCK

So we check first if argument 1 is a constant, a variable identifier (because, why not?) or a symbolic and we run ->NUM. After that, we check that we ended up either with a real or a complex number, and error if not.

This is some hybrid between what Bruce proposed (one compact command that errors if there's no match), your proposal using a list of TYPE/TYPEE numbers and my own spin checking arguments one by one in sequence rather than in bulk.

It's pretty versatile, what about 'CHECK' for the T/F version and 'CHECKFAIL' for the other one?

What I think is important is to keep the usage of negative types to differentiate between TYPEE/VTYPEE and the automatic stripping of tags à la Ck&Dispatch

BTW CHECK could return the matching type or 0 instead of a plain 1/0.

Quote:Can you think of cases where these 2 commands would fail to work well?

**EDIT**: By the way, if the depth of the stack is less than the argument number you passed to ARGCK, then it will error Bad Argument Count so that case is covered and you never need to provide an argument count.

That's good!