> The scala pattern matcher does not only discriminate on types, which was kind > of my point. If you remove all of the pattern matcher except for type tests, > and you remove the open world assumption, then you're in good shape for > totality checking. But that takes us far afield.
Indeed. It is important to understand that Scala's extractors (which are the backend for the pattern matcher) are *just* a function of type Any => Option[A] (Any => Seq[A] and Any => Boolean are also accepted, but can be considered syntactic niceties for our purposes). Functions are equivalent in power to Turing Machines, and it is not possible (in general) to predict the output of a Turing Machine without running it. We're not even talking about type systems here. Scala could be an entirely dynamic language and this property would still hold. It gets worse once you realize that extractors are late-bound at the call site, meaning that you have to consider polymorphism as well. So, not only do you need to run the extractor, but you (in the degenerate case) actually need to run the *whole program* in order to figure out what the extractor is going to be, and thus what it will do. Forget about Turing Complete type systems, simply having a Turing Complete language makes this entirely impractical. The aforementioned open world assumption also kills this idea. Incidentally, it's not strictly OO that causes problems with pattern matching: it's subtyping. I mentioned this earlier in the thread, but subtyping allows the definition of unbounded algebras. Exhaustiveness is the first thing that goes out the window in such systems. Daniel -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
