On Wednesday 23 Jun 2004 11:11 pm, John Meacham wrote:
There is a fundamental problem with assuming all []'s are equal even if they are empty lists of different things. mainly, that they arn't! see
; ghci Prelude> print ([]::[Int]) [] Prelude> print ([]::[Char]) ""
Remember, in haskell, values may depend on types. Just because the type is not explicitly expressed in the pattern, it doesn't mean it isn't there and passed around behind the scenes.
Yes I know all this, though I think it's quite backwards. Types should depend on values. Whenever people have pointed out the problems with what I'm suggesting we have always come back to type classes and overloading issues. This and other overloading problems make me think that here is where the fundamental problem really is. I also think that although the current typing restrictions on pattern matching may be justifiable because they resolve the overloading ambiguity that would otherwise result, I find the choice arbitrary. The default restricted type often isn't what the programmer wants (what this programmer often wants anyway). So if pattern matching gave (what I consider to be) the proper type of matched variables, this may occasionally cause overloading ambiguity, but why can't this be resolved the same way all other overloading ambiguities are resolved? (by using type annotation). I guess this would require scoped type variables, but I don't see any great problem with that. Of course this is all hypothetical, I don't really expect Haskell to be changed in such a fundamental way at this stage, even if there was agreement that this would be a good thing (tm) (which it seems there isn't). Regards -- Adrian Hey