[Haskell-cafe] Polymorphic algebraic type constructors

[Adrian Hey]

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