Another issues is there's lots of code polymorphic over an instance, which you lose out on if you simply make a new class rather than newtype to support an alternative instance. For instance, lots of datatypes have a second non-trivial Applicative ([] : ZipList, IO : Concurrently , Either : Validation), and there's lots of code that's polymorphic over Applicative (traverse, Data.Functor.Compose, Data.Functor.Product). Using a new class means you still need some newtype and "instance Applicative2 f => Applicative (WrappedA2 f)" to avoid duplicating all this work, so you don't really escape from needing newtypes in non-trivial examples anyway. Sean Leather-2 wrote
On Mon, Aug 24, 2015 at 1:37 PM, Clinton Mead wrote:
I see the problem now Sean. So in your example, is this correct:
"To use the machinery of 'Show', I have to add and instance Show T. But that would be an orphan instance. So there is no way for T to use show machinery without adding an orphan instance (aside from modifying a module not under your control)?"
Correct.
Even newtype doesn't seem to help in your example. Show has all this
machinery, but it seems completely unusable without adding an orphan instance or re-writing other people's modules. Is there no other way? This situation seems incredibly against re-usability, which I thought was Haskell's strength. Am I missing something?
Orphan instances are one of unfortunate pain points of Haskell, though they are sometimes a necessary “evil.” Erik's first response describes a common technique for publishing and sharing orphan instances. See, for example, https://hackage.haskell.org/packages/search?terms=instances .
Regards, Sean
_______________________________________________ Haskell-Cafe mailing list
Haskell-Cafe@
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- View this message in context: http://haskell.1045720.n5.nabble.com/Alternative-to-newtypes-or-orphan-insta... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.