[Haskell-cafe] Not too extensible records?

Olaf Klinke olf at aatal-apotheke.de
Sat Feb 27 18:20:00 UTC 2021


On Sat, 2021-02-27 at 19:59 +0500, Ignat Insarov wrote:
> 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
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




More information about the Haskell-Cafe mailing list