There is a blog post somewhere with a type-level implementation of the SKI combinator calculus, which is known to be Turing-complete. Turing-complete type systems have basically the same benefits and drawbacks that Turing-complete languages have: you can do anything, but you can prove very little. In particular, you cannot prove that you will actually eventually … 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
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
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
When someone defines a universal type ∀X they’re saying: You can plug in whatever type you want, I don’t need to know anything about the type to do my job, I’ll only refer to it opaquely as X. When someone defines an existential type ∃X they’re saying: I’ll use whatever type I want here; you … Read more
To explain it, we first have to explain nested classes in Scala. Consider this simple example: class A { class B def f(b: B) = println(“Got my B!”) } Now let’s try something with it: scala> val a1 = new A a1: A = A@2fa8ecf4 scala> val a2 = new A a2: A = A@4bed4c8 … Read more
The ability of the interpreter to deduce type and type conversions makes development time faster, but it also can provoke runtime failures which you just cannot get in a statically typed language where you catch them at compile time. But which one’s better (or even if that’s always true) is hotly discussed in the community … Read more