Re: [Haskell-cafe] Polymorphic algebraic type constructors
What you are suggesting - whilst it seems reasonable requires a fundamental change to the type system. At the moment [] signifies an empty list of type 'a' ... what you are suggesting requires [] to have a different type from [a]... This means a simple case statement : case a of (a:as) -> [] -> would now not type because everything on the LHS of the cases must be the same type. Infact I don't see how it could be any other way... 'a' has a type call it [a]... how could [] be any other type? Keean.
On Wednesday 23 Jun 2004 12:40 pm, MR K P SCHUPKE wrote:
What you are suggesting - whilst it seems reasonable requires a fundamental change to the type system. At the moment [] signifies an empty list of type 'a' ... what you are suggesting requires [] to have a different type from [a]... This means a simple case statement :
case a of (a:as) -> [] ->
would now not type because everything on the LHS of the cases must be the same type.
Infact I don't see how it could be any other way... 'a' has a type call it [a]... how could [] be any other type?
I think all occurences of [] have type forall a. [a] The case expression.. case a of (a':as) -> <expr1> [] -> <expr2> Should be typed as if written.. case a of (a':as) -> let a=(a':as) in <expr1> [] -> let a=[] in <expr2> Regards -- Adrian Hey
On Wed, 23 Jun 2004, Adrian Hey wrote:
I think all occurences of [] have type forall a. [a] The case expression.. case a of (a':as) -> <expr1> [] -> <expr2>
Should be typed as if written.. case a of (a':as) -> let a=(a':as) in <expr1> [] -> let a=[] in <expr2>
How about when a is an expression rather than just an identifier? I'm playing around with a subtyping extension to plain ol' H-M at the moment, my solution there's to let the user use an as-pattern to capture the extra type info where needed. -- flippa@flippac.org
On Wed, 23 Jun 2004, Philippa Cowderoy wrote: Not much of use. Er, I meant to cancel that upon re-reading and following things but ^X is next to ^C :-( -- flippa@flippac.org
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. John -- John Meacham - ⑆repetae.net⑆john⑈
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
participants (4)
-
Adrian Hey -
John Meacham -
MR K P SCHUPKE -
Philippa Cowderoy