Lee Spector

> `(def instruction-table ... [it's a hash map]...)` Presumably it's actually an atom containing a hash map. > `(defn registered-instructions [table] (keys table))` So you plan to pass it different...

@Vaguery: > The more desirable behavior, I suppose, is that you load only the instructions you want for that > problem into the actual interpreter you run, and then you...

> In other words, I'm not at all trying to "load more than one", but rather to enforce this restriction > at the appropriate point of responsibility: the entity which...

@Vaguery wrote: > This doesn't change in the course of a run, right? I mean, the set of instructions doesn't update in the course of any given simulation, does it?...

@Vaguery wrote: > One final question: Is there any architectural reason the instruction set is in an atom at all? So that instructions can be added incrementally, in different files...

> OK so that all just crystallized for me I'll have to see more before I know if it's a dilithium crystal or a dark crystal... > OK so now...

@Vaguery wrote: "I can just fork it" -- Noooooooooo! I absolutely super value what you're doing and want it in the master branch. Just joking about the crystals, trying to...

@Vaguery wrote: "I'm thinking of it as being encapsulated inside a persistent object..." -- Do you have a sense of how the kinds/amounts of changes this will require in existing...

@Vaguery wrote: > LOL. You easy to tease. Demonstrably. So easy that it shouldn't even be fun :-). The plan sounds good!

Bringing the currently global stuff into push-states sounds like the right idea to me too, and putting it that way helps me to see what you have in mind.