[Haskell-cafe] 'type' for isomorphism [was poorly named:
aggressiveness of functional dependencies]
Nicolas Frisby
nicolas.frisby at gmail.com
Thu Nov 16 17:17:30 EST 2006
If anyone is interested, the solution to my problem was to use a type
synonym instead of an isomorphism class.
Pros:
- Not susceptible to the functional dependencies/overlapping
instances/open-world issue
- Very simple (in fact that simplicity migrated into the rest of the system)
Cons:
- Obviously less flexible
So it works, but it wasn't quite what I had hoped for. Has there been
any work/proposals for specifying a "finalized" type class? I.E. Those
not subject to overlap and thus "closed" to the world?
Thanks,
Nick
On 11/11/06, apfelmus at quantentunnel.de <apfelmus at quantentunnel.de> wrote:
> Nicolas Frisby wrote:
> > First off, thanks for the reply.
> >
> > I am accustomed to GHC ignoring instance contexts as you mentioned.
> > It's the "mostly" part that I'm curious about: mostly implies there's
> > some phases that don't ignore context. Is that only the checking the
> > type of the method definitions and absolutely nothing else? So it
> > seems...
>
> I just said "mostly" because I don't know exactly... Though I strongly
> suspect, like you, that the preconditions are only used in type
> inference/checking and not for overlapping instances and similar
> questions related to uniqueness of instance declarations.
>
> >
> > My project is rather committed to GHC, but could you elaborate on your
> > reference to Hugs being different?
>
> By tradition from Gofer, Hugs implements type classes more flexible than
> GHC does. I once experimented with the following code using overlapping
> instances:
>
> > data Lift a = Lift a
> > type Test = Char
> >
> > class Message m o where
> > send :: m -> o -> Test
> >
> > instance Message (o -> Test) o where
> > send m o = m o
> >
> > instance Message m o => Message m (Lift o) where
> > send m (Lift o) = send m o
> >
> > msg :: Test -> Test
> > msg = id
> >
> > r1 = send msg 'a'
> > r2 = send msg (Lift 'b')
>
> It implements some kind of subtyping. GHC won't typecheck this but "hugs
> -98 +m" will. If I remember correctly, the problem was with
>
> instance Message (Lift a -> Test) (Lift a)
>
> Does this follow from the first or from the second instance declaration?
> GHC ignores the precondition in the second declaration, thus believes it
> follows from both and consequently rejects it. But Hugs has no problems
> with that: it follows the precondition and sees that the second
> declaration does not apply to the culprit because there is no (instance
> (Lift a -> Test) a). Note that if you add this instance later on
> (perhaps in a different module), things will break.
>
> The flexibility comes at a price: Gofer's type class system was unsound
> and I don't know how much Hugs comes close to this.
>
> Regards,
> apfelmus
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
More information about the Haskell-Cafe
mailing list