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

[Claudio L.]

(09-08-2021 05:21 PM)3298 Wrote:  If I may, I'd like to request replacing the simple true/false flag with an index of which type in the list matched (with 0 as placeholder for no match, like POS does). In RPL anything that isn't 0 counts as true anyway, so the value can be used for the same purposes, and performance-wise it should be a freebie, but in situations where the cases are similar but not quite the same the programmer could use this index to pull the type-specific handling code out of a list, then follow up with the common code. For instance, if your program shall accept a list or a vector and treat either as coordinates, that would allow something like this, based around AXL to coerce the input into one canonical format:

Code:

... CKARGTF
IF DUP NOT
THEN DROP "Bad Argument Type" DOERR
ELSE { AXL \<< \>> } SWAP GET EVAL
  ...
END

I like it, well thought out and minimal implementation effort on my part.

(09-08-2021 05:21 PM)3298 Wrote:  (NOP would be nice to have by the way, here I used an empty program instead. And yes, I'm using traditional RPL trigraphs instead of newRPL's Unicode glyphs; should be understandable either way.)
This kind of dispatching also opens the door to a third command that returns the index but retains the error-out on no match.

Perhaps there should be only one command that ALWAYS return a result, worst case if you don't need it just DROP it.

(09-08-2021 05:21 PM)3298 Wrote:  Side note: I'm a SysRPL programmer, but in >90% of my programs type-checking doesn't use CK&Dispatch1 or its siblings. It's not as awesome as it appears to be. Checking each stack level (or group of them, in some cases) in turns is where it's at.

Yeah, that was my experience as well, looks great on paper but doesn't help at the most basic things.

(09-08-2021 05:35 PM)JoJo1973 Wrote:  Well, Ck&Dispatch is probably best suited for Saturn architecture: your 'orthogonal' approach yields more synthetic code so I'm all for it.

[quote='JoJo1973' pid='151885' dateline='1631122553']
It's pretty versatile, what about 'CHECK' for the T/F version and 'CHECKFAIL' for the other one?

I used ARGCK, 3298 used CKARG (I think it's better than mine) and you used CHECK. I don't know, we can always leave that decision for the last minute, once we agree on the functionality of each command maybe the right the name will come to us.

(09-08-2021 05:35 PM)JoJo1973 Wrote:  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.

I like the idea of the negative numbers, but perhaps we can expand it a little more.
As far as TAGs, all tagged objects TYPE is 10000 + the type of the tagged object, so you don't really need to strip the tag to type check it.

Perhaps we could use exact/approximated numbers in the list to indicate a "loose" comparison.
where:
* First the objects are type-matched exactly.
* Tagged objects are type-matched after subtracting 10000 to the type
If the number in the argument list is exact, comparison ends here.
If there's no match, it continues as follows...
If the number in the list is approximate, additional checks are done:
* Variable names are recalled and their content is type-matched.
* Constants are replaced with their numeric values then type-matched
* Symbolic expressions are evaluated with ->NUM and the result is type-matched
* Programs are executed with XEQ and the result type-matched (that program better leave one result on the stack...)

Some examples:
10. ----> Match a real number, even when inside a variable, or an expression that evaluates to a real number, or a tagged real.
10010 -----> Match a tagged real number only, tag is required.
10010. -----> Match a tagged real inside a variable
10000 -----> Match any tagged object

We still have the negative sign to do other stuff.