Looking at rust is already beneficial
In addition to programming, I’m also a minor writer of fiction. One thing that I often do while working on a novel is write a short story to develop some aspect of craft. For example, part of the motivation for writing my story, Saint Jude’s Medallion was to work out how to tell a story through a conversation between two characters so that I could employ what I learned in the novel that I was writing at the time (which served as my MFA thesis but has since been trunked). In an analogous mode, finl functions to me as a novel and along the way, I’ll end up writing some “short story” programs to try things out and learn how to solve problems in a way that will be useful for writing finl.
The first of these “short story” programs is a mostly useless program, gftopdf, which will serve as a drop-in replacement for Knuth’s gftodvi. I have little need for this myself. It’s been decades since I wrote Metafont code seriously. But as Knuth mentions in gftodvi.web, gftodvi is a mini-TeX, and similarly, I could see using gftopdf as a mini-finl.
My gf reading code was my chance to finally implement some ideas I had played with around 1995 using function pointers as a means for simplifying the reading of a Knuthian byte file (I was thinking in terms of dvi back then, but gf is similar in spirit if not detail). I ended up creating a complicated structure using functors to implement each of the thirteen possible commands implemented over 240+ opcodes along with the four possible argument readers (1–4 bytes of signed/unsigned data). Then, while writing a post to ask about how to idiomatically implement this in rust, I realized that all the functor infrastructure was completely unnecessary. I could instead just directly implement the functors as method calls since I was building an array of lambdas anyway¹. The rust version of the code is going to be far simpler than the C++ version and only part of that (if any of it) will be due to rust. As an added bonus, I had puzzled over how the original code would be extensible for use by other programs and using virtual functions in place of functors means that my gf reading class would be able to be subclassed to enable variations on the existing functionality in the unlikely event that anyone ever cared to reuse the code.
¹ The original idea was that it was going to be an array of Opcode functor/Argument functor pairs that would be composed during the file reading loop. A combination of scoping rules and C++ syntax made that less appealing once I wrote that loop and I ended up abandoning that original plan and going with an array of lambdas instead.
Comments |0|
This site uses Akismet to reduce spam. Learn how your comment data is processed.