2023 HHC RPL Programming Contest

[3298]

This challenge is an old one, and I remember the previous iteration pretty well as Albert Chan and I made it more spicy by running off with a variant generalized to base-N. For the original one my size-optimized UserRPL take (in post #10) was 203.5 bytes long. I also had a speed-optimized one, due to different scoring criteria. The SysRPL programs in the same post were superseded by my 145-byte improvement (in post #15). That post is also where I kicked off the base-N race.
The smallest UserRPL submission was by C.Ret (in post #11) at 147.5 or 139.5 bytes, depending on whether it's entered in approximate or exact mode. It was designed for compatibility all the way down to 28C/28S, which didn't have exact mode. On machines with this mode both variants of the program work properly, the only differences are small changes in size and speed.
C.Ret also came up with a much faster program later, but it wasn't as small. It also requires exact mode on machines that have it, otherwise the trailing period added to reals in \->STR breaks the program.

I informed Gene about this repeated challenge via PM to let him take whatever action he deems appropriate, and he replied that it was an accident facilitated by a hard drive crash erasing his files on that puzzle. The on-site participants apparently didn't remember the previous iteration, which restores fairness.

Additionally, let me mention that asking for a program taking no input at all introduces a problem: it becomes possible to pre-calculate too much (e.g. \<< 381654729. \>> is definitely not acceptable), and the line between that and acceptable programs constructing that number gets blurred. For instance, how do you feel about this?

Code:

\<<
  49 57 FOR a a CHR NEXT
  9. ROLL 7. ROLLD 8. ROLL 9. ROLLD
  8. ROLL SWAP ROT 8. ROLLD
  6. ROLL 4. ROLLD 5. ROLL 6. ROLLD
  9. \->LIST \GSLIST OBJ\->
\>>

This program generates the set of digits, swaps a few around to bring them in the correct order, and concatenates them into a number. Is the swapping part too precalculated? I can't tell.
This topic is also not new, it already happened in 2019. In the 2021 iteration of this particular puzzle the base-N generalization added an input, preventing optimization past a certain (well-defined!) point. That and the raised difficulty kept it interesting for me for a while. Unfortunately, if we could prove the conjecture that there are no solutions for bases >14, that variant would also get optimized into a simple program regurgitating precalculated results.