Scala emulation of haskell type classes

Well, I don't know Scala well enough to give an answer with absolute certainty, but I do know Haskell and one of the biggest concepts regarding type classes is dictionary translation or dictionary translation. passing"). This is an implementation technique in which the compiler, given a function whose source code type requires a class, translates the function into intermediate code in which classes do not exist. A source function like the following:

sameList :: (Eq a) => [a] -> [a] -> Bool
sameList [] [] = True
sameList [] _ = False
sameList (x:xs) (y:ys) = x == y && sameList xs ys

...would translate to an intermediate code more like this:

data EqDict a = EqDict { equal :: a -> a - Bool } 

sameList :: EqDict a -> [a] -> [a] -> Bool
sameList _ [] [] = True
sameList _ [] _ = False
sameList (EqDict {equal = eq}) (x:xs) (y:ys) = 
  eq x y && sameList xs ys

...where EqDict ais a class dictionary— a dispatch table containing the class methods Eqfor the type parameter a. This is a low-level mechanism in compilers, and not a feature of Haskell itself, but it's not hard to see that armed with this concept we can take any program that uses type classes and reformulate it without them, if we write our own "dictionaries". " and pass them as arguments to all functions that need them. In the Haskell world every now and then someone recommends doing this instead of using type classes; This article (in English) seems to me to be the best known that recommends this technique.

Likewise, this shows us that in a functional language that doesn't support type classes we can nevertheless simulate them, by building our own dictionaries and passing them as explicit arguments to all functions that need them. We can do it in object-oriented languages ​​too, for example in Java:

/**
 * Interfaz que corresponde a la clase `Eq` de Haskell.
 */
interface EqDict<A> {
    boolean equal(A x, A y);
}

public static <A> boolean sameList(EqDict<A> dict, List<A> xs, List<A> ys) {
    if (xs.size() != ys.size) return false;
    for (int i = 0; i < xs.size(); i++) {
      if (!dict.equal(xs.get(i), ys.get(i))) return false;
    }
    return true;
} 

The downside is that the functions get more complicated: in the example above, the function sameListwith classes the type takes two arguments, but after translation to dictionaries it takes three. It would be very annoying to repeat this over and over again in our source programs.

And this is where the implicit arguments come into play. With such a mechanism we can use this technique of dictionaries but without having to constantly repeat them in the program. A function that requires a dictionary (or two, or three, or five) declares them as implicit arguments, and thus, when we use it from another that also requires the same implicit arguments, the language automatically takes care of communicating them.

Note however that implicit arguments have advantages and disadvantages over type classes. The big difference is that type classes guarantee that given the same class and the same type, we always get the same dictionary. Implicit arguments, on the other hand, allow different dictionaries in different parts of the program to be associated with the same type. This is a complicated topic that I cannot go into, but the cost of the additional flexibility of implicit arguments is that it also makes it easier to build bad programs.