here's my take on this (disclaimer: I've got a bit of experience in
type-class-level programming, but I'm not an expert in type systems;).
Isaac pinned the problem to MPTCs and FDs, because the former
are closely connected to when people started noticing the problem,
and the latter are intended as a partial solution. the dilemma, as far as
standardization is concerned, is that there are several variants of FDs,
and their interaction with other features, and that there is no clear
optimum in the design space yet (ghc isn't doing too badly in its
pragmatic way, but for a standard, one would prefer a consistent
story).
however, the underlying problem is not limited to MPTCs, and FDs
are not the only attempt to tackle the problem. so I agree with Isaac:
getting a handle on this issue is imperative for Haskell', because it will
be the only way forward when trying to standardize at least those of
the many extensions that have been around longer than the previous
standard Haskell 98. and if Haskell' fails to do this, it fails.
to understand my reason for this strong opinion, it is necessary to
understand that the problem underlying this dilemma not limited to
some optional extensions one might continue to ignore, but instead
is part of almost all advanced type-class programming - I'll try to
illustrate with one example.
first, here's a stripped down example of (label-type-based)
selection of fields from records (as nested tuples):
-- | field selection
infixl #?
class Select label val rec | label rec -> val where
(#?) :: rec -> label -> val
instance Select label val ((label,val),r) where
((_,val),_) #? label = val
instance Select label val r => Select label val (l,r) where
(_,r) #? label = r #? label
-- examples
data A = A deriving Show
data B = B deriving Show
data C = C deriving Show
data D = D deriving Show
r1 = ((A,True),((B,'a'),((C,1),((D,"hi there"),((B,["who's calling"]),())))))
the intention is to select the first field with a matching type of
label (question: is this intention expressed in the code? how?).
this code loads and works, with ghci-6.4.1 (and -fglasgow-exts,
-fallow-overlapping-instances), and I can select the first B field like this:
*Main> r1 #? B
'a'
the same code does *not even load* with Hugs 98 (Nov 2003) +98
(more recent releases seem to have left out the windows platform):
Hugs mode: Restart with command line option +98 for Haskell 98 mode
ERROR "C:\Documents and Settings\cr3\Desktop\haskell\haskell prime\Dilemma.hs":1
0 - Instances are not consistent with dependencies
*** This instance : Select a b (c,d)
*** Conflicts with : Select a b ((a,b),c)
*** For class : Select a b c
*** Under dependency : a c -> b
this demonstrates the dilemma, and I hope it also shows why I want these
extensions standardized, at the very least as an addendum defining all the
options out there in current use. this is not about saying that every
implementation has to support FDs, but about clarifying what is supported.
we can modify the example a bit, to get to the underlying problem. here's
a Select', without the functional dependency:
-- | field selection
infixl #.
class Select' label val rec where
(#.) :: rec -> label -> val
instance Select' label val ((label,val),r) where
((_,val),_) #. label = val
instance Select' label val r => Select' label val (l,r) where
(_,r) #. label = r #. label
now this loads in both ghci and hugs, but it doesn't quite work to our
satisfaction:
Main> r1 #. B
ERROR - Unresolved overloading
*** Type : Select' B a () => a
*** Expression : r1 #. B
*Main> r1 #. B
<interactive>:1:3:
Overlapping instances for Select' B val
((B, Char), ((C, Integer), ((D, [Char]), ((B, [[Char]]), ()))))
arising from use of `#.' at <interactive>:1:3-4
Matching instances:
Dilemma.hs:10:0: instance (Select' label val r) =>
Select' label val (l, r)
Dilemma.hs:7:0: instance Select' label val ((label, val), r)
(The choice depends on the instantiation of `val'
Use -fallow-incoherent-instances to use the first choice above)
In the definition of `it': it = r1 #. B
note, btw, that ghci offers a dangerous-sounding workaround, for the
adventurous, but this isn't actually going to help, because it only offers
to default to the recursive instance, soon running out of record to
select from (and no reordering of source-code seems to affect that
choice):
*Main> :set -fallow-incoherent-instances
*Main> r1 #. B
<interactive>:1:3:
No instance for (Select' B val ())
arising from use of `#.' at <interactive>:1:3-4
Probable fix: add an instance declaration for (Select' B val ())
In the definition of `it': it = r1 #. B
back to the problem: there are multiple instances matching the
context required to fulfill our selection request, and since the choice
of instance might affect the program result, neither implementation
is willing to commit to one of the choices (unless explicitly encouraged
by a daring option;).
so far, so good. we can resolve the ambiguity with a type annotation:
Main> r1 #. B ::Char
'a'
*Main> r1 #. B::Char
'a'
everybody happy? not at all! recall our original FD: we wanted the
result to be dependent on the field selected, not the field selection
dependent on the result requested!
Main> r1 #. B ::[String]
["who's calling"]
*Main> r1 #. B::[String]
["who's calling"]
oops. if we go back to the original code (and hence ghci only), we
get the error message we expected, because the first B field in r1
holds a Char value, not a [String]:
*Main> r1 #? B::[String]
Top level:
Couldn't match `Char' against `[String]'
Expected type: Char
Inferred type: [String]
When using functional dependencies to combine
Select label val ((label, val), r),
arising from the instance declaration at Dilemma.hs:20:0
Select B
[String]
((B, Char), ((C, Integer), ((D, [Char]), ((B, [[Char]]), ())))),
arising from use of `#?' at <interactive>:1:3-4
by now, you'll probably have an idea what the problem is (at least,
the problem as I see it): selection from ambiguous instances, and
committing to one of several choices.
to hammer home the point that this is not specific to MPTCs, but
inherent in complex type-class level programming, here's the
ambiguous version again, without any MPTCs:
class Select' t where
(#.) :: t
instance Select' (((label,val),r)->label->val) where
((_,val),_) #. label = val
instance Select' (r->label->val) => Select' ((l,r)->label->val) where
(_,r) #. label = r #. label
this version loads fine into hugs, but not into ghci:
*Main> :r
Compiling Main ( Dilemma.hs, interpreted )
Dilemma.hs:10:0:
Non-type variables in constraint: Select' (r -> label -> val)
(Use -fallow-undecidable-instances to permit this)
In the context: (Select' (r -> label -> val))
While checking the context of an instance declaration
In the instance declaration for `Select' ((l, r) -> label -> val)'
Failed, modules loaded: none.
undecidable instances is ghc jargon for "i don't have to care what
these instances look like. just don't blame me.". once we've signed
that disclaimer, we get the same problems, without any MPTCs
in sight:
Main> r1 #. B ::Char
'a'
Main> r1 #. B ::[String]
["who's calling"]
*Main> r1 #. B::Char
'a'
*Main> r1 #. B::[String]
["who's calling"]
the reason that this problem starts to show up with MPTCs is that,
with conventional limitations on instances in place, MPTCs were one
of the first extensions that permitted multiple variables to be constrained
by one type-class constraint. once those limitations are relaxed (as
well they should be), there are other uses of type classes that exhibit
the same issue.
the reason that FDs are connected with this problem is that they are
trying to address part of it, by allowing us to turn type-level relations
(type-class constraints involving multiple types) into type-level
functions, so that resolving only a subset of type variables in such a
constraint will be sufficient to commit to an instance.
so, once again, the problem is *selection from possibly ambiguous
instances*, and *control over that selection*. and this problem seems
to be inherent in type-class-level programming, with or without
MPTCs or FDs. the problem is aggravated by the wish to support
separate compilation of modules, because it means that the
implementation can never know that there won't be another
fitting instance just around the corner.. this leads to the slightly
ridiculous situation that the implementation will sometimes not
even select the one and only instance we ever intended to write.
note that I said "possibly ambiguous", because, really, there
shouldn't be any ambiguity in this case (and in many other cases).
usually, it is just that Haskell (or the Haskell+ implementation at
hand) does not give us the means to express our intentions in
an unambiguous form. and that is not for not trying, either. to wit,
have a look at some of the language features that have tried to
address parts of the problem (or that have been proposed):
- defaults (remember those?)
- functional dependencies
- "most-specific" rule in overlapping instances
- incoherent instances (is the selection documented anywhere?)
- closed classes (yes, dear compiler, you can see *all* instances)
it may also be worth pointing out the one language feature that
does *not* try to help with the problem:
- ignoring contexts when deciding about overlaps
because, often, the contexts establish mutually exclusive
pre-conditions to those "overlapping" instances. so, this is a lot
like ignoring guards when matching patterns.. and if we were
able to specify negation of type predicates (the characteristic
predicates of those type relations specified by MPTCs),
avoiding overlaps by such constraints would be even easier.
well, I could go on, but that's probably more than enough for
now. thanks for reading with us, we hope you had an enjoyable
trip!-)
cheers,
claus