Thank you for your kind suggestions, Olaf and Henning.
I am looking into an extensible record based solution for the sake of extensibility and convenience. I could certainly manage everything with a bunch of tuples, but that would require writing a huge number of `HasThis` and `HasThat` instances and even then would not provide the flexibility I should like.
For example, suppose I have two functions: one is a layout algorithm that assigns to nodes some spatial positions, and the second is a topological algorithm that discerns roots and leaves. These two functions are conceptually independent and may be applied in any order, but it seems to me that as many as 5 types would be needed to handle this situation: `label`, `(label, V2 Double)`, `(label, Topology)`, `((label, V2 Double), Topology)` and `((label, Topology), V2 Double)`. And what if there is another quality independent of these two? The number of permutations goes through the roof.
So, it seems to me that some smart technology is needed to make this manageable. Precisely. And I advocate that this might be ordinary type classes. While the number of combinations is exponential, you'd only write the
On Sat, 2021-02-27 at 19:59 +0500, Ignat Insarov wrote: base and inductive cases for HasFoo. The compiler would figure out the rest. I suggest you look at the machinery in the mtl package. There, a very similar problem is solved: Different types are stacked on top of each other, in any order and depth, and each type provides a certain functionality. Yet in any combination, each functionality in the stack is available at the top level. Olaf