type-systems

问题 With Haskell's type classes it almost seems that it enables ad hoc polymorphism, but its functions declarations seem parametric polymorphism. Am I mixing my understanding of different things? 回答1: Indeed, Haskell supports both (higher rank) parametric polymorphism, and ad hoc (or bounded ) polymorphism. Parametric polymorphism in Haskell is supported via its Hindley-Milner/System F type system. Ad hoc polymorphism is supported via type classes. For the origin of type classes and ad hoc

问题 I was trying to solve this problem with shapeless. However I am for some reason unable to map on the HList . I'll let the code speak for itself. import shapeless._ import HList._ case class Foo(a: Option[Int], b: Option[Int]) val a = Foo(Some(3), None) val b = Foo(Some(22), Some(1)) implicit val fooIso = HListIso(Foo.apply _, Foo.unapply _) val mapper = new (({ type O2[+A] = (Option[A], Option[A]) })#O2 ~> Option) { def apply[A](x: (Option[A], Option[A])): Option[A] = x._1.orElse(x._2) }

问题 There are claims that Scala's type system is Turing complete. My questions are: Is there a formal proof for this? How would a simple computation look like in the Scala type system? Is this of any benefit to Scala - the language? Is this making Scala more "powerful" in some way compared languages without a Turing complete type system? I guess this applies to languages and type systems in general. 回答1: There is a blog post somewhere with a type-level implementation of the SKI combinator

问题 In Scala, the syntax for selecting a type from a class is different from that of selecting anything else from a class. In that the former uses a hash as the selection operator instead of a dot. Why is that? Example: If we have a class like so... class Example { type Foo = String } Why do we select the type from the class like this... val example:Example#Foo = "1" instead of like this? val example:Example.Foo = "1" 回答1: Example#Foo is called a type projection and will match any type Foo of any

问题 Assuming I have a type hierarchy like the following: trait Color case class Red(r: String) extends Color case class Green(g: String) extends Color Is it possible to create a method that accepts a Seq[Color] that contains elements of either all Red , or either all Green , but not both? For example in the following code: def process[T](colors: Seq[T]) = colors.size process(Seq(Red("a"), Green("g"))) what should [T] be so that the above does not type-check? Edit The original problem is the

问题 I have always worked on statically typed languages (C/C++, Java). I have been playing with Clojure and I really like it. One thing I am worried about is: say that I have a windows that takes 3 modules as arguments and along the way the requirements change and I need to pass another module to the function. I just change the function and the compiler complains everywhere I used it. But in Clojure it won't complain until the function is called. I can just do a regex search and replace but it

问题 In Haskell, I often have a function like f , which accepts a list and returns a list of equal length: f :: [a] -> [a] -- length f(xs) == length xs Similarly, I might have a function like g , which accepts two lists that should be of equal length: g :: [a] -> [a] -> ... If f and g are typed as above, then run-time errors may result if their length-related constraints are not satisfied. I would therefore like to encode these constraints in the type system. How might I do this? Please note that

问题 In Agda, there is Set n . As I understand, Set n extends the Haskell-style value-type-kind hierarchy to infinite levels. That is, Set 0 is the universe of normal types, Set 1 is the universe of normal kinds, Set 2 is the universe of normal sorts, etc. In contrast, Idris has the so called "cumulative hierarchy of universes". It seems that for a < b , Type a: Type b , and universe levels are inferred. But what does it mean in real world programs? Can't we define something that only operate on

问题 Is there any reason why Scala's Ordering trait is not contravariant? A motivating example follows. Suppose I want to perform an ordered insert. I may have a function with the signature def insert[A, B >: A](list: List[A], item: A)(implicit ord: Ordering[B]): List[A] Here, I have an Ordering which accepts super types of type A . I imagine this is useful when you're dealing with case classes . For example: abstract class CodeTree case class Fork(left: CodeTree, right: CodeTree, chars: List[Char

问题 What are type projections in Scala useful for? Why does Scala's type system support both type projections and path dependent types? What was the rationale behind this design decision? 回答1: Not a complete answer, but here are some uses for type projections that I have encountered: Type level metaprogramming . For examples, see Michid's series (parts I, II, III), Jesper's implementation of HList, and the series at Apocalisp. A workaround to enable type inference (for examples, here are some