[I suggest to keep follow-on discussions to the haskell prime list,
to avoid further copies]
continuing the list of odd cases in type class handling, here is a
small example where overlap resolution is not taken into account
when looking at FDs.
actually, one needs to take both into account to arrive at the
interpretation I favour:
- variables in the range of an FD can never influence instance
selection if the variables in the domain of that FD are given
(for, if they did, there'd be two instances with different range
types for the same domain types -> FD violation)
- in other words, FDs not only tell us that some type relations
are functional, they can be seen as roughly similar to what is
called mode declarations in logic programming: they tell us
with which input/output combinations a type relation may
be used
- for each FD a given constraint is subject to, the range types
should be ignored during instance selection: the domain types
of the FD constitute the inputs and are sufficient to compute
unique FD range types as outputs of the type relation. the
computed range types may then be compared with the range
types given in the original constraint to determine whether the
constraint can be fulfilled or not
if we apply these ideas to the example I gave, instance resolution
for the "3 parameter, with FD"-version proceeds exactly as it
would for the "2 parameter"-version, using best-fit overlap
resolution to determine a unique 3rd parameter (range of FD)
from the first two (domain of FD).
this would seem similar to what we do at the function level:
f a b | let res = True, a==b = res
f a b | let res = False, otherwise = res
here, the implementation does not complain that f isn't functional
because we could instantiate {a=1,b=1,res=False} as well as
{a=1,b=1,res=True} - instead it treats res as output only, a and b
as input, and lets first-fit pattern matching resolve the overlap in
the patterns. these rules describe a function because we say it does.
whereas, at the type class level, the implementations say "okay,
you said this is a type function, with two input and one output
parameters, but if I ignore that for the moment, then overlap
resolution doesn't kick in because of the different 3rd input
parameter, and now there are two instances where there should
only be one {TEQ a a T, TEQ a a F}; and if I now recall
that this should be a type function, I have to shout 'foul!'".
am I the only one who thinks this does not makes sense?-)
cheers,
claus
{- both ghc and hugs accept without 3rd par and FD
neither accepts with 3rd par and FD -}
data T = T deriving Show
data F = F deriving Show
class TEQ a b {- tBool | a b -> tBool -} where teq :: a -> b -> Bool
instance TEQ a a {- T -} where teq _ _ = True
instance TEQ a b {- F -} where teq _ _ = False
test = print (teq True 'c', teq True False)
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
