HHC 2016 RPL Programming Contest

[DavidM]

(09-19-2016 08:36 PM)Wes Loewer Wrote:  I'm always amazed at how specific the commands are: DUP4UNROLL, OVERLEN$, POSCHRREV. I half expected there to be a command called MAXDISTCHAR$.

Some SysRPL commands are specialized (like those you've mentioned above), but some others are simply a call to another SysRPL subroutine that does the indicated steps. I've always assumed that the latter of these were done simply to save precious space in the firmware. If you can replace even a small amount of 10-nibble command sequences with 5-nibble ones, you've saved more than enough space to justify the creation of a separate subroutine. That's probably one of the reasons there are so many special-case combo SysRPL commands.

(09-19-2016 08:36 PM)Wes Loewer Wrote:  It's funny how the brain works. When I got it down to 138 bytes, I was convinced I had done the very best I could. Then I saw something that I could do to reduce it further, and further, and further, each time fully convinced that I was absolutely done. Optimizing is a very psychological process.

It is. After looking at your code, I realized that I had an incorrect assumption in my head about the TAIL command, so I revisited that. I recoded the initial translation block of my program and saved a few bytes, but it ended up with a leftover null string at the end of the list. Purely by accident, this extra null string ended up helping the overall program by alleviating the need to handle single character inputs as a special case. Those changes (and one other small one) ended up saving 17.5 bytes. It's still way too big compared to a more traditional approach, but a nice savings.

But here's the catch: the code is now even harder to understand (IMHO). It's smaller, but some of its intended function is purely accidental and not at all obvious unless you painstakingly trace through the code (or provide copious comments to explain why things happen the way they do). And if I ever needed to re-use the code for a similar purpose, it probably wouldn't be as suitable.

Perhaps it's simply the types of problems I tend to code (combined with my lack of familiarity), but I still find that the list processing tools are often "a nail in search of a hammer". But I'll keep trying to find the hammer.