@Chance mind looking at this to see if you can tell why `e<space>` got detokenized? It just happens to work (I think. All the 0mo's stay in the same spots and the total tokens are the same) but I can't figure out how I caused that.
Awesome. So I took advantage of the s's we could add to RK to cut out some alphuck filler. Then I found out that os could replace the ax that Moorhens was using. I moved the detokenization of <space>2 to earlier in the line so that is also helps with Prelude padding (and then removed a space from several lines up to also detokenize '<space>.
Also, I don't remember if I linked this earlier but if you need to check what command an Moorhens word would create you can use this. It won't tell you if it's in Moorhen's dictionary, though:
perhaps we should add the incident link to the incident answer, too? it's linked from the wiki page
but a direct link to the interpreter might be useful
I need (when I have more time to focus on things like that) to write an interpreter that doesn't have libdivsufsort as a dependency, so that it runs on TIO
@Chance if I run it as .f95, I get a ton of warnings followed by a ton of errors; the warnings are "illegal preprocessor directive", meaning that many of the lines starting with # are acceptable to gfortran, but some lines (such as the line with the Moorhens code) contain errors despite starting with #
the first error on that line is at character 35 (which I think is the 7 of 27.say; not sure how it numbers exactly though), "Invalid character in name"
possibly harder to fix is "Unexpected PROGRAM statement" on line 72; this is concerning both because a) it implies that the Fortran section itself is broken, and b) the polyglot doesn't even have 72 lines