[Haskell-beginners] special polymorphic default of typeclass depending on other typeclasses?

[Silent Leaf]

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 at 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 at 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20170629/ae54d807/attachment-0001.html>