Consider this: in all decent programming languages you can write functions, e.g. def f(arg) = result Here, f takes a value arg and computes a value result. It is a function from values to values. Now, some languages allow you to define polymorphic (aka generic) values: def empty<T> = new List<T>() Here, empty takes a … Read more
If you already have a b : Bool, you can turn it into proposition: So b, which is a bit shorther than b ≡ true. Sometimes (I don’t remember any actual case) there is no need to bother with a proper data type, and this quick solution is enough. So seems to have serious disadvantages … 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
I think the trick here is that you don’t enforce it on the type-level, you use “smart constructors”: i.e. only allow creation of such “tuples” via a function that generates such values: module Test(MyType,x,y,z,createMyType) where data MyType = MT { x :: Int, y :: Int, z :: Int } createMyType :: Int -> Int … Read more
When you see a family of types, you may wonder whether each of the arguments it has are parameters or indices. Parameters are merely indicative that the type is somewhat generic, and behaves parametrically with regards to the argument supplied. What this means for instance, is that the type List T will have the same … Read more
Syntactic convenience aside, the combination of singleton types, path-dependent types and implicit values means that Scala has surprisingly good support for dependent typing, as I’ve tried to demonstrate in shapeless. Scala’s intrinsic support for dependent types is via path-dependent types. These allow a type to depend on a selector path through an object- (ie. value-) … Read more