3 ms·

I don't think that matters in this case. The list of node-types is static in the context of the execution of the program so there is no need for nodes of the sa

I don't think that matters in this case. The list of node-types is static in the context of the execution of the program so there is no need for nodes of the same types to have different behaviour, apart from the data/configuration that they store. The point in question was what happens if new node-types come in (e.g. through a plugin that extends the language). But in this case the number of node-types is still static and the new functionality can therefore be adapted using type-classes.

3cats-in-a-coat 3y ago
The assumption it's a closed system that received no new content at runtime is a very functional programming-like assumption, but quite restrictive in most real long-lived systems.
- valenterry 3y ago
  That's not the assumption. The assumption is that the system does not receive new node-types at runtime. Think of the JVM: you can load new bytecode (e.g. classes) at runtime, but you can't load bytecode that contains features of newer jvm versions that isn't compatible with the existing one. I don't think this is a "functional programming-like assumption".