[Haskell-cafe] Re: [Haskell] View patterns in GHC: Request for feedback

apfelmus apfelmus at quantentunnel.de
Thu Jul 26 08:02:42 EDT 2007


Dan Licata wrote:
> apfelmus wrote:
>> The idea is to introduce a new language extension, namely the ability to
>> pattern match a polymorphic type. For demonstration, let
>>
>>   class ViewInt a where
>>     view :: Integer -> a
>>
>>   instance ViewInt [Bool] where
>>     view n = ... -- binary representation
>>
>>   data Nat = Zero | Succ Nat
>>
>>   instance ViewInt Nat where
>>     view n = ... -- representation as peano number
>>
>> be some views of the integers. Now, I'd like to be able to write
>>
>>   bar :: (forall a . ViewInt a => a) -> String
>>   bar Zero      = ...
>>   bar (True:xs) = ...
> 
> This doesn't make sense to me:
> 
> Zero :: Nat 
> 
> and therefore
> 
> Zero :: ViewInt Nat => Nat
> 
> but you can't generalize from that to 
> 
> Zero :: forall a. ViewInt a => a
> 
> E.g., Zero does not have type ViewInt [Bool] => Bool

Yes, the types of the patterns don't unify. But each one is a
specialization of the argument type. Note that the type signature is

  bar :: (forall a . ViewInt a => a) -> String

which is very different from

  bar :: forall a . ViewInt a => a -> String

Without the extension, we would write  bar  as follows

  bar :: (forall a . ViewInt a => a) -> String
  bar x = let xNat = x :: Nat in
     case xNat of
       Zero -> ...
       _    -> let xListBool = x :: [Bool] in
          case xListBool of
             True:xs -> ...

In other words, we can specialize the polymorphic argument to each
pattern type and each equation may match successfully.

> Maybe you wanted an existential instead

No. That would indeed mean to pick the matching equation by analysing
the packed type, i.e. some equations don't match since their patterns
have the wrong type. I think that such a thing violates parametricity.

Regards,
apfelmus



More information about the Haskell-Cafe mailing list