Re: Fundeps and quantified constructors
--- Tom Pledger [EMAIL PROTECTED] wrote: anatoli writes: : | The same error message is given for | | data Foo a = (Eq b) = MkFoo b Since the type variable a is orphaned, how about reducing it to this? data Foo = forall b . Eq b = MkFoo b This is possible (the semantics is different of course). What I want to do is, given a multi-parameter context, orphan one type variable leaving the other intact, and that's not possible now. I can only orphan all or preserve all. so that MkFoo :: Eq b = b - Foo | I don't know whether this is intended behaviour; IMHO | it should be treated identically to | | data Foo a = MkFoo (Eq a = a) Isn't the Foo-ed a hidden by the Eq-ed a in this example too? i.e. data Foo = MkFoo (forall a . Eq a = a) It appears that both examples are wrong, or at least Hugs thinks so. The first MkFoo happily accepts any type, not just of class Eq: Main :t MkFoo head MkFoo head :: Foo ([a] - a) The second accepts nothing of interest: Main :t MkFoo 'a' ERROR: Inferred type is not general enough *** Expression: 'a' *** Expected type : Eq a = a *** Inferred type : Eq Char = Char Hm... The more I experiment with this, the less I understand. It seems that the only correct place to put the quantifier is before the data constructor, and the context may go either before the type constructor or after the quantifier. This is very unfortunate. How can I correctly write something to this effect: data Quick a = Eq a = Unsorted [a] | Ord a = Sorted (Tree a) ??? Regards -- anatoli __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Fundeps and quantified constructors
Hi everybody:
I think I've found what's the problem. Still no solution in sight :(
The problem has nothing to do with fundeps. Consider an example:
data Foo a = (Eq a) = MkFoo a
This gives the same error message: type variable a is not locally
bound. Apparently, 'a' in 'Eq a' hides 'a' in 'Foo a' instead of
using it. The same error message is given for
data Foo a = (Eq b) = MkFoo b
I don't know whether this is intended behaviour; IMHO
it should be treated identically to
data Foo a = MkFoo (Eq a = a)
Hugs accepts either
data Eq a = Foo a = MkFoo a
or
data Eq a = MkFoo (Eq a = a)
with no problem, but neither syntax works with Collection:
the first one would look like
data forall c. Collection c e = AnyColl e = MkColl c
which is a syntax error, and the second one
data AnyColl e = forall c . MkCall (Collection c e = c)
or alternatively
data AnyColl e = MkCall (forall c . Collection c e = c)
gives me 'Ambiguous type signature in type component' error.
{
Apparently Hugs is still buggy in the fundep/multiparameter
classes area; I have an example where Hugs assigns garbage types
to things when fundeps are involved. This is probably a
hugs-bugs issue.
}
Now to the question:
--- Tom Pledger [EMAIL PROTECTED] wrote:
Does it introduce any new implementation issues? When a constructor
like MakeSomeCollection is applied, some implementations gather a
dictionary of methods appropriate for use with the existentially
quantified type, right?
I believe that in the general case all implementation must do so, in one
form or another.
Is that more difficult when it involves a
non-locally bound type variable? Even when that type variable is
constrained by a fundep?
I believe there should be no implementation problems. In order to gather the
dictionary, an implementation must know the type of the argument to
MakeSomeCollection. When this type (say T) is known, the compiler just finds
'instance Collection T whatever' declaration. There can be only one such
instance (because of the fundep). All needed methods are specified there.
Regards
--
anatoli
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
