On Sat, 27 Feb 2021, Ignat Insarov wrote:
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.
Before thinking about a new type extension to the already complicated type system with its many extensions I would try to solve the problem with the existing machinery. I think the existing solutions can solve your problem and you do not know whether extensible records would really simplify your code in the end.
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.
What about a record with parameters: data EdgeLabel label vector topology = EdgeLabel {label :: label, vector :: vector, topology :: topology} You can easily disable a field by using the unit type (), i.e. your type my type label EdgeLabel label () () (label, V2 Double) EdgeLabel label (V2 Double) () (label, Topology) EdgeLabel label () Topology ((label, V2 Double), Topology) EdgeLabel label (V2 Double) Topology My experience is that working with a fixed (but maybe large) number of type parameters is much easier than trying to cope with different shapes of nested tuples, extending types, wrappers.