2 ms·

Typeclasses dispatch is static. You can use a typeclass implementation as a proxy for holding a dynamically injected implementation you call through the typecla

Typeclasses dispatch is static. You can use a typeclass implementation as a proxy for holding a dynamically injected implementation you call through the typeclass implementation, but that's a hack, not exactly "elegant".

valenterry 3y ago
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".
deredede 3y ago
Can you elaborate on what you mean by "typeclass dispatch is static"? I believe typeclasse in Haskell at least are lowered to an array of method, i.e. a vtable, and (single) dispatch happens at runtime.
- whateveracct 3y ago
  Yep they desugar to dictionary-passing (vtable)..buuuut GHC is a helluva optimizing compiler and will often effectively make them static.
  - deredede 3y ago
    I mean, sure, you can optimize a lot of the common cases (C++ compilers do the same), but that doesn't make the dispatch static, semantically.
    - whateveracct 3y ago
      It's static dispatch when it's monomorphic, I'd say.

valenterry 3y ago

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".

deredede 3y ago

Can you elaborate on what you mean by "typeclass dispatch is static"? I believe typeclasse in Haskell at least are lowered to an array of method, i.e. a vtable, and (single) dispatch happens at runtime.

whateveracct 3y ago
Yep they desugar to dictionary-passing (vtable)..buuuut GHC is a helluva optimizing compiler and will often effectively make them static.
- deredede 3y ago
  I mean, sure, you can optimize a lot of the common cases (C++ compilers do the same), but that doesn't make the dispatch static, semantically.
  - whateveracct 3y ago
    It's static dispatch when it's monomorphic, I'd say.