you're right my example is more like Show, it's because i change two times the order of input and output, and did not check at the end if it was what i wanted...

Actually i did not mean constraints on instances, especially thereafter ad-hoc polymorphic instances.

I rather meant what i said, as in default implementation (as in, right inside the body of the class).

like that:

class Foo a where

  bar :: a -> String

  bar :: Show a => a -> String

  bar = show -- default implementation: in other terms, if you define an instance without defining this method

the idea would be then that if you have Foo (), you can either implement a special version, or leave it to show. mind you i'm not even sure we can define an instance without any specific implementation of method?

--that would be allowed:

instance Show => Foo () where

  -- nothing, if it's even legal by default

-- and of course that would be allowed to if someone wanted a special function bar :: Foo () => () -> String

instance Foo () where

  bar = ....

obviously, i do not mean *both* instances of Foo (), just, one or the other. it would merely be a way to implement ad-hoc polymorphism onto *default implementations of methods*, that is, those inside the body of the class.

2017-06-29 19:45 GMT+02:00 David McBride <toad3k@gmail.com>:

This is a common mistake that people who try to use type classes run
into.  I remember banging my head against it pretty hard when I first
started out.

There's this temptation that  you should be able to write the following:

class Foo a where
  bar :: a  -> String

instance Read a => Foo a where
  bar a = read a

instance Foo () where
  bar _ = "bar"

But the problem with that is that now () applies to two conflicting
classes.  It is both a Read and a Foo. So when you go bar (), which
instance should fire?  The Foo instance or the Read () => Foo
instance?

There are a multitude of ways you could try to resolve this.  Let's
say obviously the Read constrainted instance is more specific, we
should use that.  But then what if the user of your library happens to
have a instance Ord a => Foo a in his library, now which one of those
is more specific?  Read or Ord?

Because of all these ambiguities during type checking ghc doesn't even
look at the constraint.  It would see instance Foo a, and instance Foo
(), and then say oh! those are overlapping instances because () could
apply to either class before you consider what constraints apply.

There's actually several very in depth answers on stackoverflow for
this questions like this, such as this one:
https://stackoverflow.com/a/3216937/1500583  It might give you some
ideas on what to do about this.

On Thu, Jun 29, 2017 at 1:15 PM, Silent Leaf <silent.leaf0@gmail.com> wrote:
> hi,
>
> say i have the following typeclass:
>
> class Foo a where
>   bar :: a  -> String
>
> looks a lot like the Read typeclass, right? (at least i think it should?)
> well say it's a different meaning (in other terms i can't or do not want to
> use Read, but i'd like to implement a default version of bar for those
> instances that also implement Read. is there a way to do so?
>

> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners