Problem with functional dependencies

4 Jan 2001 22:33:50 GMT

Thu, 4 Jan 2001 13:01:56 -0800, Mark P Jones <mpj@cse.ogi.edu> pisze:

> I hope now that the problem is becoming clear: this instance
> declaration is not consistent with the dependency; in the first
> two lines above, for example, we see two rows that violate the
> specification because they have the same value of "a", but different
> values for "b" and "c".

I see. So fundeps are not capable of expressing what I hoped, and what
a related but simpler concept I talked about once can express. I wonder
if there are practical uses of fundeps which are not expressible by
this concept.

What I have in mind is the following. A subset of type variables
of a class is chosen. Only that subset is used to find an instance
for resolving constraints with this class. The instance chosen
determines the rest of types. Instances must make this possible,
i.e. be non-unifiable wrt. the active subset of type variables. Voila.

An extended variant: several such subsets instead of one. Probably
each subset should be considered independently, with their results
unified. Or something like that.

This provides an equivalent of types contained in classes in C++.

It does not matter if the passive types in an instance use additional
type variables. This is where fundeps fail.

Having types with type variables which are never instantiated nor
constrained should be equivalent to having ground types!

Why, oh why haven't a more friendly and less problematic concept been
used, instead of fundeps which forever can't be finished in ghc and
have some different semantics in Hugs?

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK