What is the difference between F[A] and A? - scala

For languages like Scala and Haskell, you can construct types using type constructors. What is the right vocabulary for differentiating between all of these parts?
A is a type. F[A] is also a type. Is there language that exists to differentiate the two?
What is A?
What is F[A]?
What is F?

Dunno about in Scala, but in Haskell, the Report does distinguish between two syntactic categories: "types" and "constructors". Constructors are just those types which are single atoms, beginning with an upper case letter, and created by data and newtype declarations. e.g.
data Foo a = Bar
creates a new type constructor Foo (and a new data constructor Bar), and types can be formed by applying Foo to another type. Of course, constructors need not be of higher kind; data Baz = Quux also declares a type constructor named Baz which is not permitted to be applied to any other types.
(But beware: it is common to use "type constructor" to mean "any type-level expression with an arrow kind", so if you are doing some technical writing, you should include some text in your introduction clarifying which of these two meanings you intend to use in the rest of the document.)
So, in your example, we could say Map is a constructor, Char is a constructor, Int is a constructor, Map Char is a type, and Map Char Int is a type.
As far as I know, there is no common shorthand term for any of these categories: "a type which is definitely not a constructor", "a type of kind *", "a type which is definitely not of kind *". For types which are allowed to be applied to another type, there is the term "higher-kinded type" -- e.g. Map and Map Char are both higher-kinded types.

I would propose to just call F[A] application of a type constructor F of kind * -> * to the argument A of kind *. "Type constructor" comes from the specification, whereas "application" comes from the basic lambda calculus, as explained below.
Recall that the formalism of higher-kinded types with all the type constructors is essentially just an extension of a simply typed lambda calculus over a single type *.
That means that you have the following rules for forming kinds:
* is a kind
if a, b are kinds, then a -> b is a kind
You can form terms as follows:
Predefined constants with fixed kind are terms
Variables are terms
If f and a are terms, then the application f a is a term
If x is a variable name, and y is a term, then the abstraction \x.y is a term
You can check whether a (type-valued) term is well-kinded with rules that look somewhat like this:
Predefined constant c of kind k (vacuously) has kind k, regardless of context
If context Gamma contains mapping of a variable v to kind k, then in Gamma we can infer that v is a well-kinded expression of kind k.
If in context Gamma we can infer that f has kind a -> b and x has kind a, then the application f x has kind b.
If in context Gamma, x: a we can infer that y has kind b, then in Gamma we can infer that \x.y has kind a -> b.
I don't see any reason to invent any new vocabulary, so I would just use "application".
An aside: you can actually write down the above basic kind-inference algorithm really quickly.
sealed trait Term
case class Apply(func: Term, arg: Term) extends Term
case class Lam(preferred: String, dom: Type, body: Term) extends Term
case class BoundVar(deBruijnIdx: Int) extends Term
case class FreeVar(name: String) extends Term
sealed trait Type
case object * extends Type
case class Func(dom: Type, cod: Type) extends Type {
override def toString = s"($dom -> $cod)"
}
import util.{Either, Left, Right}
case class Ctx(globalConstants: Map[String, Type], stack: List[Type]) {
def push(tp: Type): Ctx = Ctx(globalConstants, tp :: stack)
def pop: Ctx = Ctx(globalConstants, stack.tail)
}
object Ctx {
def empty = Ctx(Map.empty, List.empty)
def emptyWithGlobals(keys: (String, Type)*) = Ctx(keys.toMap, Nil)
}
def tinf(t: Term, ctx: Ctx = Ctx.empty): Either[String, Type] = t match {
case FreeVar(v) =>
ctx.globalConstants.get(v).map(Right(_)).getOrElse(Left("Undefined: " + v))
case BoundVar(d) => Right(ctx.stack(d))
case Apply(f, x) =>
for {
tf <- tinf(f, ctx)
tx <- tinf(x, ctx)
res <- tf match {
case Func(a, b) =>
if (tx == a) Right(b)
else Left(s"Type mismatch: cannot apply `$a` to `$b`")
case sthElse => Left(s"Not applicable: $sthElse")
}
} yield res
case Lam(_, tp, b) =>
for {
tb <- tinf(b, ctx.push(tp))
} yield Func(tp, tb)
}
for {
example <- List(
Lam("x", *, BoundVar(0)),
Lam("x", *, Lam("y", Func(*, *), Apply(BoundVar(0), BoundVar(1))))
)
} println(example + " : " + tinf(example))
and it will happily infer that type-lambdas
\(x:*).x
\(x:*).\y(* -> *). y x
have the kinds
(* -> *)
(* -> ((* -> *) -> *))
respectively.

The technical terms, as mentioned in the comments, are 'type', 'some other type', and a 'type constructor'.
Consider:
data A = A
-- ^ ^--- The Data Constructor
-- -- The type
data F x = SomeDataConstructorForF x
-- ^ ^ ^-- Data Constr ^-- Field
-- | --- Type Variable
-- - Type Constructor
val :: A
val = A
-- A value of type 'A'
val2 :: F [A]
val2 = SomeDataConstructorForF []
-- A value of some other type, F [A].
-- No special term exists for types built through application
-- of one or more type constructor afaik

Related

why in Scala a function type needs to be passed in separate group of arguments into a function

I am new to scala , I have written same code in 2 ways . But i am bit confused between 2 ways. In Second way argument type of f are derived automatically but in type1 scala compiler is not able to do the same . I just want to understand what is the thought behind this .
Type1: Gives compilation error
def rightFold[A,B](xs:List[A],z:B,f:(A,B) => B ): B = xs match {
case Nil => z
case Cons(x,xs) => f(x,rightFold(xs,z,f))
}
def sum1(l:List[Int]) = rightFold(l,0.0,_ + _)
Type2 : Works fine
def rightFold[A,B](xs:List[A],z:B)(f:(A,B) => B ): B = xs match {
case Nil => z
case Cons(x,xs) => f(x,rightFold(xs,z)(f))
}
def sum1(l:List[Int]) = rightFold(l,0.0)(_ + _)
Type inference flows from left-to-right through argument lists. In other words, type information from left argument lists is available in right argument lists, but argument types within the same list are inferred independently.
This is not about function types need to be passed in a separate group of arguments (currying).The problem is with your usage of + on types that the Scala doesn't know about yet.
When you curry a function, the compiler is able to infer the type of the first two arguments as being List[Int] and Double already. This allows the + to be resolved as it knows that the types are Int and Dobule on the two sides.
Now why can't the compiler do the same with the single arguments list - that's just how it is, type information is not available within an argument list.
Type 1 would work if instead of passing in _ + _ you pass in (a: Int, b: Double) => (a + b)). Currying the function lets you use the underline syntax, because the scala compiler has inferred what types A and B are by the time you try and pass in the addition function.
With single list an inferred type of A depends on the types of xs and f. But with the two lists of arguments it depends just on the xs type.

Scala: Typecast without explicitly known type parameter

Consider the following example:
case class C[T](x:T) {
def f(t:T) = println(t)
type ValueType = T
}
val list = List(1 -> C(2), "hello" -> C("goodbye"))
for ((a,b) <- list) {
b.f(a)
}
In this example, I know (runtime guarantee) that the type of a will be some T, and b will have type C[T] with the same T. Of course, the compiler cannot know that, hence we get a typing error in b.f(a).
To tell the compiler that this invocation is OK, we need to do a typecast à la b.f(a.asInstanceOf[T]). Unfortunately, T is not known here. So my question is: How do I rewrite b.f(a) in order to make this code compile?
I am looking for a solution that does not involve complex constructions (to keep the code readable), and that is "clean" in the sense that we should not rely on code erasure to make it work (see the first approach below).
I have some working approaches, but I find them unsatisfactory for various reasons.
Approaches I tried:
b.asInstanceOf[C[Any]].f(a)
This works, and is reasonably readable, but it is based on a "lie". b is not of type C[Any], and the only reason we do not get a runtime error is because we rely on the limitations of the JVM (type erasure). I think it is good style only to use x.asInstanceOf[X] when we know that x is really of type X.
b.f(a.asInstanceOf[b.ValueType])
This should work according to my understanding of the type system. I have added the member ValueType to the class C in order to be able to explicitly refer to the type parameter T. However, in this approach we get a mysterious error message:
Error:(9, 22) type mismatch;
found : b.ValueType
(which expands to) _1
required: _1
b.f(a.asInstanceOf[b.ValueType])
^
Why? It seems to complain that we expect type _1 but got type _1! (But even if this approach works, it is limited to the cases where we have the possibility to add a member ValueType to C. If C is some existing library class, we cannot do that either.)
for ((a,b) <- list.asInstanceOf[List[(T,C[T]) forSome {type T}]]) {
b.f(a)
}
This one works, and is semantically correct (i.e., we do not "lie" when invoking asInstanceOf). The limitation is that this is somewhat unreadable. Also, it is somewhat specific to the present situation: if a,b do not come from the same iterator, then where can we apply this type cast? (This code also has the side effect of being too complex for Intelli/J IDEA 2016.2 which highlights it as an error in the editor.)
val (a2,b2) = (a,b).asInstanceOf[(T,C[T]) forSome {type T}]
b2.f(a2)
I would have expected this one to work since a2,b2 now should have types T and C[T] for the same existential T. But we get a compile error:
Error:(10, 9) type mismatch;
found : a2.type (with underlying type Any)
required: T
b2.f(a2)
^
Why? (Besides that, the approach has the disadvantage of incurring runtime costs (I think) because of the creation and destruction of a pair.)
b match {
case b : C[t] => b.f(a.asInstanceOf[t])
}
This works. But enclosing the code with a match makes the code much less readable. (And it also is too complicated for Intelli/J.)
The cleanest solution is, IMO, the one you found with the type-capture pattern match. You can make it concise, and hopefully readable, by integrating the pattern directly inside your for comprehension, as follows:
for ((a, b: C[t]) <- list) {
b.f(a.asInstanceOf[t])
}
Fiddle: http://www.scala-js-fiddle.com/gist/b9030033133ee94e8c18ad772f3461a0
If you are not in a for comprehension already, unfortunately the corresponding pattern assignment does not work:
val (c, d: C[t]) = (a, b)
d.f(c.asInstanceOf[t])
That's because t is not in scope anymore on the second line. In that case, you would have to use the full pattern matching.
Maybe I'm confused about what you are trying to achieve, but this compiles:
case class C[T](x:T) {
def f(t:T) = println(t)
type ValueType = T
}
type CP[T] = (T, C[T])
val list = List[CP[T forSome {type T}]](1 -> C(2), "hello" -> C("goodbye"))
for ((a,b) <- list) {
b.f(a)
}
Edit
If the type of the list itself is out of your control, you can still cast it to this "correct" type.
case class C[T](x:T) {
def f(t:T) = println(t)
type ValueType = T
}
val list = List(1 -> C(2), "hello" -> C("goodbye"))
type CP[T] = (T, C[T])
for ((a,b) <- list.asInstanceOf[List[CP[T forSome { type T }]]]) {
b.f(a)
}
Great question! Lots to learn here about Scala.
Other answers and comments have already addressed most of the issues here, but I'd like to address a few additional points.
You asked why this variant doesn't work:
val (a2,b2) = (a,b).asInstanceOf[(T,C[T]) forSome {type T}]
b2.f(a2)
You aren't the only person who's been surprised by this; see e.g. this recent very similar issue report: SI-9899.
As I wrote there:
I think this is working as designed as per SLS 6.1: "The following skolemization rule is applied universally for every expression: If the type of an expression would be an existential type T, then the type of the expression is assumed instead to be a skolemization of T."
Basically, every time you write a value-level expression that the compiler determines to have an existential type, the existential type is instantiated. b2.f(a2) has two subexpressions with existential type, namely b2 and a2, so the existential gets two different instantiations.
As for why the pattern-matching variant works, there isn't explicit language in SLS 8 (Pattern Matching) covering the behavior of existential types, but 6.1 doesn't apply because a pattern isn't technically an expression, it's a pattern. The pattern is analyzed as a whole and any existential types inside only get instantiated (skolemized) once.
As a postscript, note that yes, when you play in this area, the error messages you get are often confusing or misleading and ought to be improved. See for example https://github.com/scala/scala-dev/issues/205
A wild guess, but is it possible that you need something like this:
case class C[+T](x:T) {
def f[A >: T](t: A) = println(t)
}
val list = List(1 -> C(2), "hello" -> C("goodbye"))
for ((a,b) <- list) {
b.f(a)
}
?
It will type check.
I'm not quite sure what "runtime guarantee" means here, usually it means that you are trying to fool type system (e.g. with asInstanceOf), but then all bets are off and you shouldn't expect type system to be of any help.
UPDATE
Just for the illustration why type casting is an evil:
case class C[T <: Int](x:T) {
def f(t: T) = println(t + 1)
}
val list = List("hello" -> C(2), 2 -> C(3))
for ((a, b: C[t]) <- list) {
b.f(a.asInstanceOf[t])
}
It compiles and fails at runtime (not surprisingly).
UPDATE2
Here's what generated code looks like for the last snippet (with C[t]):
...
val a: Object = x1._1();
val b: Test$C = x1._2().$asInstanceOf[Test$C]();
if (b.ne(null))
{
<synthetic> val x2: Test$C = b;
matchEnd4({
x2.f(scala.Int.unbox(a));
scala.runtime.BoxedUnit.UNIT
})
}
...
Type t simply vanished (as it should have been) and Scala is trying to convert a to an upper bound of T in C, i.e. Int. If there is no upper bound it's going to be Any (but then method f is nearly useless unless you cast again or use something like println which takes Any).

Type for Traversable that maps to same kind of Traversable

Short version. Most generic collections in Scala have a map method which will, in fact, return a collection of the same type. (List[A].map(f:A=>B) returns a List[B], for example.) The Scala collection library was explicitly designed to achieve this. What if I want to write code that is polymorphic over any such collection? Can "Traversable whose map behaves like a functor's does" be expressed as a type?
Long version. I have a situation where it would be useful to have an abstraction representing a collection of objects of some Current type, such that if those objects were converted to some Desired type, then the collection could use those objects to construct an object of some Result type. I can achieve pretty much everything I want just by using the function type
(C => D) => R
but one defect of this approach is the excessive laziness (in the context my application) of the natural map method, which would be something like
def map[C2](f: C=>C2): (C2=>D)=>R = (g => this(f andThen g))
This delays the application of f to the objects of type C until the R is being computed. I'd rather apply f immediately.
So, for example, I might implement something like
class Foo[+C,-D,+R](cs: List[C], finalize: List[D]=>R) {
def apply(f: C=>D): R = finalize(cs.map(f))
def map[C2](f: C=>C2): Foo[C2,D,R] = Foo(cs.map(f), finalize)
}
So far so good. But now I think to myself, there's nothing special about List here; any type constructor that implemented some kind of map function would do. The only thing is that the function finalize might rely on the structure of the collection. Maybe the first element of the list is treated specially, for example, so if the List.map returned some more general type of collection, perhaps a very abstract one that didn't even have a notion of "first element", then finalize could fail. Likewise if it expects the list to be a certain length but I filter the list or something.
This kind of problem cannot arise if I write the code in its natural generality, something like
class Foo[+C,-D,+R,F[x] <: Traversable[x]](cs: F[C], finalize: F[D]=>R) {
...
}
because then I can't accidentally do anything weird with the F (unless I inspect its type at runtime or something, in which case I deserve what I get).
The only remaining problem is that cs.map(f) has static type Traversable[D], not F[D], although of course we expect that it's actually of type F[D] usually, and the Scala collection library was explicitly designed to ensure that that is so.
So my question is, can this requirement on F be expressed in the types?
Essentially, I want the Scala version of the Haskell code
data Foo f b r a = Foo (f a) (f b -> r)
instance (Functor f) => Functor (Foo f b r) where
g `fmap` (Foo fa fbr) = Foo (g `fmap` fa) fbr
dothething :: (Functor f) => Foo f b r a -> (a -> b) -> r
dothething foo g = fbr fb where Foo fb fbr = g `fmap` foo
with more or less the same guarantees and without laziness.
Are you looking for Functor from scalaz?
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Functor.scala
It allows you to do abstract over anything that can fulfill the type class definition.
def addTwo[F[_]](f: F[Int])(implicit F: Functor[F]): F[Int] = f.map(_+2)
Now my 'addTwo' method does not care what is being mapped, as long as there exists a functor instance. So both of these would work:
addTwo(List(1,2,3))
addTwo(Future { 1 } )
etc.

Scala - Make signature of function parameter f of higher order function g dependent on varars of g

I am trying to define a higher order function f which accepts a variable number of parameters args of type Wrapper[T]* and a function parameter g in Scala.
The function f should decapsulate each object passed in args and then call g with the decapsulated parameters. Therefore, g has to accept exactly the same number of parameters of type T as args contains.
The closest thing I could achieve was to pass a Seq[T] to g and to use pattern matching inside of g. Like the following:
f("This", "Is", "An", "Example")(x => x match {
case Seq(a:String, b:String, c:String): //Do something.
})
With f defined like:
def f[V](args: Wrapper[T]*)
(g: (Seq[T]) => (V)) : V = {
val params = args.map(x => x.unwrap())
g(params)
}
How is it possible to accomplish a thing like this without pattern
matching?
It is possible to omit the types in the signature of g
by using type inference, but only if the number of parameters is
fixed. How could this be done in this case?
It is possible to pass
different types of parameters into varargs, if a type wildcard is
used args: Wrapper[_]*. Additionally, casting the result of
x.unwrap to AnyRef and using pattern matching in g is
necessary. This, however, completely breaks type inference and type
safety. Is there a better way to make mixing types in the varargs
possible in this special case?
I am also considering the use of scala makros to accomplish these tasks.
Did I get you right? I replaced your Wrapper with some known type, but that doesn't seem to be essential.
def f[T, V](args: T*)(g: PartialFunction[Seq[T], V]): V = g(args)
So later you can do this:
f(1,2,3) { case Seq(a,b,c) => c } // Int = 3
Okay, I've made my own Wrapper to be totally clear:
case class Wrapper[T](val x:T) {
def unwrap = x
}
def f[V](args: Wrapper[_]*)(g: PartialFunction[Seq[_], V]): V =
g(args.map(_.unwrap))
f(Wrapper("1"), Wrapper(1), Wrapper(BigInt(1))) {
case Seq(s: String, i: Int, b: BigInt) => (s, i, b)
} // res3: (String, Int, BigInt) = (1,1,1)
Regarding your concerns about type safety and conversions: as you can see, there aren't any explicit conversions in the code above, and since you are going to pattern-match with explicitly defined types, you may not to worry about these things - if some items of an undefined origin are going to show in your input, scala.MatchError will be thrown.

Impredicative types vs. plain old subtyping

A friend of mine posed a seemingly innocuous Scala language question last week that I didn't have a good answer to: whether there's an easy way to declare a collection of things belonging to some common typeclass. Of course there's no first-class notion of "typeclass" in Scala, so we have to think of this in terms of traits and context bounds (i.e. implicits).
Concretely, given some trait T[_] representing a typeclass, and types A, B and C, with corresponding implicits in scope T[A], T[B] and T[C], we want to declare something like a List[T[a] forAll { type a }], into which we can throw instances of A, B and C with impunity. This of course doesn't exist in Scala; a question last year discusses this in more depth.
The natural follow-up question is "how does Haskell do it?" Well, GHC in particular has a type system extension called impredicative polymorphism, described in the "Boxy Types" paper. In brief, given a typeclass T one can legally construct a list [forall a. T a => a]. Given a declaration of this form, the compiler does some dictionary-passing magic that lets us retain the typeclass instances corresponding to the types of each value in the list at runtime.
Thing is, "dictionary-passing magic" sounds a lot like "vtables." In an object-oriented language like Scala, subtyping is a much more simple, natural mechanism than the "Boxy Types" approach. If our A, B and C all extend trait T, then we can simply declare List[T] and be happy. Likewise, as Miles notes in a comment below, if they all extend traits T1, T2 and T3 then I can use List[T1 with T2 with T3] as an equivalent to the impredicative Haskell [forall a. (T1 a, T2 a, T3 a) => a].
However, the main, well-known disadvantage with subtyping compared to typeclasses is tight coupling: my A, B and C types have to have their T behavior baked in. Let's assume this is a major dealbreaker, and I can't use subtyping. So the middle ground in Scala is pimps^H^H^H^H^Himplicit conversions: given some A => T, B => T and C => T in implicit scope, I can again quite happily populate a List[T] with my A, B and C values...
... Until we want List[T1 with T2 with T3]. At that point, even if we have implicit conversions A => T1, A => T2 and A => T3, we can't put an A into the list. We could restructure our implicit conversions to literally provide A => T1 with T2 with T3, but I've never seen anybody do that before, and it seems like yet another form of tight coupling.
Okay, so my question finally is, I suppose, a combination of a couple questions that were previously asked here: "why avoid subtyping?" and "advantages of subtyping over typeclasses" ... is there some unifying theory that says impredicative polymorphism and subtype polymorphism are one and the same? Are implicit conversions somehow the secret love-child of the two? And can somebody articulate a good, clean pattern for expressing multiple bounds (as in the last example above) in Scala?
You're confusing impredicative types with existential types. Impredicative types allow you to put polymorphic values in a data structure, not arbitrary concrete ones. In other words [forall a. Num a => a] means that you have a list where each element works as any numeric type, so you can't put e.g. Int and Double in a list of type [forall a. Num a => a], but you can put something like 0 :: Num a => a in it. Impredicative types is not what you want here.
What you want is existential types, i.e. [exists a. Num a => a] (not real Haskell syntax), which says that each element is some unknown numeric type. To write this in Haskell, however, we need to introduce a wrapper data type:
data SomeNumber = forall a. Num a => SomeNumber a
Note the change from exists to forall. That's because we're describing the constructor. We can put any numeric type in, but then the type system "forgets" which type it was. Once we take it back out (by pattern matching), all we know is that it's some numeric type. What's happening under the hood, is that the SomeNumber type contains a hidden field which stores the type class dictionary (aka. vtable/implicit), which is why we need the wrapper type.
Now we can use the type [SomeNumber] for a list of arbitrary numbers, but we need to wrap each number on the way in, e.g. [SomeNumber (3.14 :: Double), SomeNumber (42 :: Int)]. The correct dictionary for each type is looked up and stored in the hidden field automatically at the point where we wrap each number.
The combination of existential types and type classes is in some ways similar to subtyping, since the main difference between type classes and interfaces is that with type classes the vtable travels separately from the objects, and existential types packages objects and vtables back together again.
However, unlike with traditional subtyping, you're not forced to pair them one to one, so we can write things like this which packages one vtable with two values of the same type.
data TwoNumbers = forall a. Num a => TwoNumbers a a
f :: TwoNumbers -> TwoNumbers
f (TwoNumbers x y) = TwoNumbers (x+y) (x*y)
list1 = map f [TwoNumbers (42 :: Int) 7, TwoNumbers (3.14 :: Double) 9]
-- ==> [TwoNumbers (49 :: Int) 294, TwoNumbers (12.14 :: Double) 28.26]
or even fancier things. Once we pattern match on the wrapper, we're back in the land of type classes. Although we don't know which type x and y are, we know that they're the same, and we have the correct dictionary available to perform numeric operations on them.
Everything above works similarly with multiple type classes. The compiler will simply generate hidden fields in the wrapper type for each vtable and bring them all into scope when we pattern match.
data SomeBoundedNumber = forall a. (Bounded a, Num a) => SBN a
g :: SomeBoundedNumber -> SomeBoundedNumber
g (SBN n) = SBN (maxBound - n)
list2 = map g [SBN (42 :: Int32), SBN (42 :: Int64)]
-- ==> [SBN (2147483605 :: Int32), SBN (9223372036854775765 :: Int64)]
As I'm very much a beginner when it comes to Scala, I'm not sure I can help with the final part of your question, but I hope this has at least cleared up some of the confusion and given you some ideas on how to proceed.
#hammar's answer is perfectly right. Here is the scala way of doint it. For the example i'll take Show as the type class and the values i and d to pack in a list :
// The type class
trait Show[A] {
def show(a : A) : String
}
// Syntactic sugar for Show
implicit final class ShowOps[A](val self : A)(implicit A : Show[A]) {
def show = A.show(self)
}
implicit val intShow = new Show[Int] {
def show(i : Int) = "Show of int " + i.toString
}
implicit val stringShow = new Show[String] {
def show(s : String) = "Show of String " + s
}
val i : Int = 5
val s : String = "abc"
What we want is to be able run the following code
val list = List(i, s)
for (e <- list) yield e.show
Building the list is easy but the list won't "remember" the exact type of each of its elements. Instead it will upcast each element to a common super type T. The more precise super super type between String and Int being Any, the type of the list is List[Any].
The problem is: what to forget and what to remember? We want to forget the exact type of the elements BUT we want to remember that they are all instances of Show. The following class does exactly that
abstract class Ex[TC[_]] {
type t
val value : t
implicit val instance : TC[t]
}
implicit def ex[TC[_], A](a : A)(implicit A : TC[A]) = new Ex[TC] {
type t = A
val value = a
val instance = A
}
This is an encoding of the existential :
val ex_i : Ex[Show] = ex[Show, Int](i)
val ex_s : Ex[Show] = ex[Show, String](s)
It pack a value with the corresponding type class instance.
Finally we can add an instance for Ex[Show]
implicit val exShow = new Show[Ex[Show]] {
def show(e : Ex[Show]) : String = {
import e._
e.value.show
}
}
The import e._ is required to bring the instance into scope. Thanks to the magic of implicits:
val list = List[Ex[Show]](i , s)
for (e <- list) yield e.show
which is very close to the expected code.