Hi! I'm still studying the theory of Haskell, but i also wanted to start dabbling with guideless coding, all by myself, and it happens experience is just as much important as theoretical knowledge! I'm not surprise mind you :P<br><br>Say there's a class, many types that can instantiate it. Then, i in fact need to be able to concatenate (mappend would be ideal!), make lists of values of different types, all instantiating the class.<br><br>I'm a bit lost on this. There are at least two sorts of ways to handle said group of types, but i'm not certain either is best, and i'm not even very much satisfied about either. Plus they don't specifically differ as regards handling of listing or otherwise interacting *between* different instances of the same class (or alternately, different types born from the same Type constructor).<br><br>First idea i had, was based on making a class indeed, as well i just love this type of polymorphism (visavis other paradigms). Each type would only have to instantiate the key metshods, and no need of wrappers to use said methods, so on this respect it's pretty great.<br>However, as soon as we want operations between values of different types, it rather gets tricky.<br>The only way i know of to make a heterogeneous list is to use ExistentialQuantificators, create a newtype (or data?) wrapper for the class, allowing for any type to be in, without parameters.<br>Now, the problem i have with this, is the wrapping: if i wanna make a list of types, i gotta wrap all values, and if this list becomes member of a superlist of the same polymorphic type, i gotta wrap this very sublist again with the "class wrapper". Maybe i'm imagining problems and i won't actually need to touch too much to the wrapping if i write the correct functions or instances, but from where i am, permanent wrapping seems tiresome, very much in fact removes the purpose of a class: to allow polymorphic functions without need to wrap the types of inputs/outputs inside a newtype.<br><br>Which lead me to the second solution: forget the class, and make a type constructor that basically gets a list of key-methods and one field for the wrapped type. Basically it amounts to OOP, at least it seems so. I'm not really a big fan of the thing, and eventually i realized it wouldn't help me more visavis trans-type methods, especially an idea of one or more monoidal instances for the class, or the type constructor that replaces it.<br>(Actually I'm not wholly certain as of how I'm supposed to handle Type constructors instead of classes, as I only know how to make heterogeneous out of a class, not out of a type constructor, even if its polymorphic key-methods are fields included in it. (hope i'm being clear enough, don't hesitate telling me otherwise!)<br><br>So, as I'm kinda beginner as regards actual coding, i'm asking advice on the subject. Maybe the problem is in how i look at the problem, and I shouldn't even be there trying to do what i try to do. Any alternative solution or viewpoint is heartily welcome!<br>I resume my problem once more: how to handle cross-type interactions and grouping when they only have a class in common, and if possible without having to use ExistentialQuantificators, unless there's a way to keep the wrappers far away, invisible, automatic.<br><br>Thanks a lot in advance! (Ideas of specialized tutorials are also very much welcome!)