[SOLVED] DSRN (dog slow roman numerals)

[Claudio L.]

(06-16-2014 03:40 AM)DavidM Wrote:  The algorithm in DM1/TK3 doesn't handle 0 or negative values properly. So as I'm in the mood of late to force myself to use the list-processing commands more, I thought I'd fix that. In the process I ran into yet another DOLIST quirk.

What would you expect the result of DOLIST to be when presented with the following? These are the values in the lists at that step when 0 is the original input value to the DM1/TK3 apps:

Code:

{ "M" "CM" "D" "CD" "C" "XC" "L" "XL" "X" "IX" "V" "IV" "I" }
{  0   0    0   0    0   0    0   0    0   0    0   0    0  }
2 \<< NDUPN DROP \>> DOLIST

My expectation was { }, since NDUPN would delete all the strings and DROP would get rid of all the resulting Ns. The actual result: nothing. No list, no error message, nothing.

So accommodating that scenario requires an additional list-processing workaround. The one I chose wasn't too involved: I added yet another list at the top of that step that was filled with empty strings. This guaranteed that there was always some kind of result for the DOLIST step, and that output won't adversely affect the final string. It also ended up negating the need to work around the \GSLIST quirk as well. But as expected, it made the code bigger, a bit slower, and somewhat uglier all at the same time.

I really want to like the list processing commands. This application is clearly not a good one for them, though.

Yes, we've also changed that already in newRPL. Makes no sense to get nothing! The empty list is the correct answer, no doubt.
As much as we wanted 100% compatibility, there's things we consider design problems and we are not willing to replicate that.
Want another one? The number of lists is an optional argument, and the system is supposed to correctly guess, under some obscure circumstances only, how many arguments it needs. The AUR gives an example of the command << DUP >>, which I tested and... didn't work (Bad Argument count). So it's optional in some cases but it's either not clear when, or it doesn't work as designed (or at least as explained in the AUR). So we opted to make the parameter not optional.

Hopefully our implementation of list processing commands will be more "likable" than the original.

Claudio