Thank you for providing this resource! Regarding this annotation:
It is possible to solve nearly every level with an appropriate Narcissus/Hero/Leander definition and a level definition like "(narcissus) 2 dip dig do", which I'm opting to not allow for this sheet.
Could you demonstrate with an example?
For a useless example, here's a solution to Caesar: (narcissus) 3 dip 3 dig (16) (23) between do
A definition of Narcissus that makes this solve work is: 3 zap(3 zap(?)(3 caesar)zap copy format)(3 caesar)zap copy format
You could imagine applying this to something with a long solution like Thirteen to save some symbols on Thirteen, though of course at the cost of making Narcissus longer. You can also construct an even better definition of Narcissus that can detect the input (especially for levels where it is significantly different than those in Narcissus) so you don't need the between.
If you haven't solved Narcissus yet on the savefile, I'm pretty you can just put some code in and it can be used in other levels despite not actually being a quine, so you could just throw a "3 caesar" in Narcissus' textbox with no problem. Once the level is solved once this seems to not work anymore though.
P.S. I removed a bunch of the solutions you added to the side because this isn't a resource for casual solves; it's specifically for symbol optimization. The multiply solution was cool though, so I optimized it a bit and left it in.
Thank you for the explanation! So you literally embed a solution in the narcissus quine then use that invocation that extracts the solution back out.So you will get a size optimization "cheese" in the case that the solution embedded in narcissus is longer than the invocation code that extracts it.
So narcissus, hero and leander can be used as some data storage if you can craft a quine or a double quine in the case of hero/leander that can embed your data!
No worries about removing the solutions I added, that's completely your prerogative. Thanks to your sheet, I was about to study and learn a whole bunch of solving tricks I wasn't aware of, such as using do after a bracketed number to unbracket it and put it in the execution stack as a prefix for an X verb. Or the fact that a bunch of unbracketed numbers together get added by the interpreter for "free" before being interpreted as a prefix for an X verb.
Nothing was spoiled for me, because I really just wanted to learn these very clever stack manipulating techniques, see them in action and appreciate all the meta programming possibilities and expressiveness of stack programming. Prior to this, whenever I saw Forth, I couldn't look past the limitations that stack manipulations seemed to impose. So many very interesting things to learn from the solutions.
