[Haskell-cafe] Re: type families and type signatures
apfelmus
apfelmus at quantentunnel.de
Fri Apr 11 05:22:18 EDT 2008
Tom Schrijvers wrote:
> apfelmus wrote:
>> However, I have this feeling that
>>
>> bar :: forall a . Id a -> String
>>
>> with a type family Id *is* parametric in the sense that no matter
>> what a is, the result always has to be the same. Intuitively, that's
>> because we may not "pattern match on the branch" of a definition like
>>
>> type instance Id String = ..
>> type instance Id Int = ..
>> ..
>
> But in a degenerate case there could be just this one instance:
>
> type instance Id x = GADT x
>
> which then reduces this example to the GADT case of which you said that
> is was "clearly parametric".
Manuel M T Chakravarty wrote:
> type instance Id [a] = GADT a
Oh right, just setting the instance to a GADT makes it non-parametric.
Still, it's not the type family that is the problem, but "parametricity"
is not the right word for that. What I want to say is that although the
type signature
bar :: forall a . Id a ~ b => b -> String
looks ambiguous, it is not. A trivial example of "seeming" ambiguity
would be (foo :: forall a . Int) . Here, parametricity tells us that
this is not ambiguous.
The proper formulation is probably: a value f :: forall a . t is
/unambiguous/ iff any choices a1, a2 for a that yield the same
static type necessarily also yield the same dynamic value
t[a1/a] = t[a2/a] -- types are equal
=> f @ a1 = f @ a2 -- values are equal
In the case of bar , this would mean that anything not injective like
type instance Id Int = Int
type instance Id Char = Int
would not change the dynamic semantics of bar at all, i.e. (bar @ Int
:: Int -> String) = (bar @ Char :: Int -> String).
I believe that this is indeed the case for bar and for type synonym
families in general. (Not so for type classes, of course.)
Regards
apfelmus
More information about the Haskell-Cafe
mailing list