let it leave me like a long breath

BUT THEN ACTUALLY:

okay so the point of that code is that it makes it possible to represent combinatorics equations using only O(n+m) space for the options, instead of O(n*m) that you'd use from exhaustively listing all of them. this gets to be a very big deal when you have some quattuordecillion options or so but your individual components are only a few thousand.

HOWEVER

that Applicative instance has to exhaustively list all of the options! due to the way it works, it ends with a big nested list that ultimately contains one of each possible permutation. like, the code works and all it's just got abysmal space/time complexity. even something as simple as enumerating color space (a paltry 3.6 million options in the space i'm using) would make it lag and freeze.

so i had to think about how my space-saving code actually worked and i ended up writing some variant functions that i'm calling <<$>> and <<*>> which work just like <$> and <*> save that they require the function to have its first argument be a monoid (and thus by implication require all arguments to be monoids), and using some TRICKERY they manage to store function application in slices that are later combined together

previously i had thought of my monoid constraint on pick as kind of arbitrary but it turns out it's actually super important

anyway, having done this now i can start to rework the existing parser to actually use this type, so that's neat



oh yeah and i worked some on hell game! i took a bit of a break b/c i was super burnt out on it, but yesterday i finally dug into the completed code files and started patching them together so they'd actually compile.

i think all these adventures in parsers has definitely shown me that data entry can be much much simpler when you can control the data format; i had been thinking about making a scene editor script kinda thing, and now i think i'd be halfway competent at putting that together. something to add onto the todo list, i guess.