A function with signature Num a => a is expected to work for any type in the class Num. The implementation 5.0 :: Double just works for one type, not for all types of the class, so the compiler complains. An example of a generic function would be: square :: (Num a) => a -> … Read more
Example#Foo is called a type projection and will match any type Foo of any enclosing instance of type Example. If you write a type Example.Foo, the compiler will look for the value (and not type) called Example and will refer to its enclosing Foo type only. This is often used in the context of singleton … Read more
Note: In this answer I will use the dyn Trait syntax to make it more clear when a type is a trait object. The older way to write Rc<dyn Trait> is Rc<Trait>. See What does “dyn” mean in a type? No, you can’t downcast Rc<dyn Trait> to Rc<Concrete>, because trait objects like dyn Trait don’t … Read more
Dependently Typed Haskell, Now? Haskell is, to a small extent, a dependently typed language. There is a notion of type-level data, now more sensibly typed thanks to DataKinds, and there is some means (GADTs) to give a run-time representation to type-level data. Hence, values of run-time stuff effectively show up in types, which is what … Read more
There’s an easy fix: just define your function as an object instead of a val: object f extends (({ type O2[+A] = (Option[A], Option[A]) })#O2 ~> Option) { def apply[A](x: (Option[A], Option[A])): Option[A] = x._1 orElse x._2 } (Note that I’ve named the function f instead of mapper to avoid confusion with the mapper implicit … Read more
Both newtype and the single-constructor data introduce a single value constructor, but the value constructor introduced by newtype is strict and the value constructor introduced by data is lazy. So if you have data D = D Int newtype N = N Int Then N undefined is equivalent to undefined and causes an error when … Read more
Upcasts can be checked at compile time – the type system guarantees that the cast succeeds. Downcasts cannot (in general) be checked at compile time, so they are always checked at runtime. Unrelated types cannot be cast to each other. The compiler considers only the static types. The runtime checks the dynamic (runtime) type. Looking … Read more
More or less any use of member (ie. nested) types can give rise to a need for dependent method types. In particular, I maintain that without dependent method types the classic cake pattern is closer to being an anti-pattern. So what’s the problem? Nested types in Scala are dependent on their enclosing instance. Consequently, in … Read more
Great question! There are several key differences. Representation A newtype guarantees that your data will have exactly the same representation at runtime, as the type that you wrap. While data declares a brand new data structure at runtime. So the key point here is that the construct for the newtype is guaranteed to be erased … Read more
My favorite example: case class Board(length: Int, height: Int) { case class Coordinate(x: Int, y: Int) { require(0 <= x && x < length && 0 <= y && y < height) } val occupied = scala.collection.mutable.Set[Coordinate]() } val b1 = Board(20, 20) val b2 = Board(30, 30) val c1 = b1.Coordinate(15, 15) val c2 … Read more