Hello, In the library I am writing, I declare a type Vector for Data.Vector Double. I then create a Num instance for it as it doesn't have one yet. GHC tells me that this instance is an orphan. After reading several answers to issues like mine, I want to get rid of these orphans. The advice I saw mostly is to use the newtype keyword. Is there a way to do it nicely, instead of copying most of the API of Data.Vector ? Now, the only thing I can see is do like in this example: import Data.Vector as V newtype VectorD = VectorD (V.Vector Double) map :: (Double -> Double) -> VectorD -> VectorD map f (VectorD v) = VectorD $ V.map f v Is there a better way ? Best regards, Adrien
On Mon, Feb 06, 2012 at 10:31:50AM +0100, Adrien Haxaire wrote:
Hello,
In the library I am writing, I declare a type Vector for Data.Vector Double. I then create a Num instance for it as it doesn't have one yet. GHC tells me that this instance is an orphan. After reading several answers to issues like mine, I want to get rid of these orphans. The advice I saw mostly is to use the newtype keyword.
Is there a way to do it nicely, instead of copying most of the API of Data.Vector ?
Now, the only thing I can see is do like in this example:
import Data.Vector as V
newtype VectorD = VectorD (V.Vector Double)
map :: (Double -> Double) -> VectorD -> VectorD map f (VectorD v) = VectorD $ V.map f v
Is there a better way ?
Yes: don't bother. Having an orphan instance is really not that big of a deal. And it's certainly not worth making a newtype just to avoid the warning. If you want to turn off the warning you can add {-# OPTIONS_GHC -fno-warn-orphans #-} to the top of your file. -Brent
Thank you. It will save me some time, and I will be happy using the nice API of Data.Vector without having to wrap everything. I will still read more on orphan instances to be sure I understand the concept and the consequences, even if now I know they are minor for me. Adrien On Mon, 6 Feb 2012 08:53:14 -0500, Brent Yorgey wrote:
Yes: don't bother. Having an orphan instance is really not that big of a deal. And it's certainly not worth making a newtype just to avoid the warning. If you want to turn off the warning you can add
{-# OPTIONS_GHC -fno-warn-orphans #-}
to the top of your file.
-Brent
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
The concept is simple: an orphan instance is an instance instance Class Type ... which is in neither the module where Class is declared, nor the module where Type is declared. In your case, both 'Num' and 'Data.Vector' are defined elsewhere. One reason you might not want this is because many people might define identical or similar instances for the same types, so if/when that instance is actually added to the module defining the type or class in question it will break a lot of code. But in my mind this is not an argument *against* orphan instances but rather an argument *for* contributing instances back upstream (which is certainly a good idea when it makes sense). For example if you think the Num instance for Data.Vector is something that would be generally useful you can submit a patch to the Data.Vector maintainer, and then delete the instance from your module when a new version of Data.Vector is released. However, sometimes there are good reasons not to do this -- for example if (say) the implementation of the Num instance for Data.Vector relied on some *other* package and it was desirable not to add this other package as a dependency for Data.Vector. I seem to recall there is also something about GHC having to do more work for orphan instances, but I don't recall the details. And I am not sure why I should have to change my code to save GHC some work -- I want *GHC* to work harder to save *me* work, not the other way around. -Brent On Mon, Feb 06, 2012 at 04:25:05PM +0100, Adrien Haxaire wrote:
Thank you.
It will save me some time, and I will be happy using the nice API of Data.Vector without having to wrap everything.
I will still read more on orphan instances to be sure I understand the concept and the consequences, even if now I know they are minor for me.
Adrien
On Mon, 6 Feb 2012 08:53:14 -0500, Brent Yorgey wrote:
Yes: don't bother. Having an orphan instance is really not that big of a deal. And it's certainly not worth making a newtype just to avoid the warning. If you want to turn off the warning you can add
{-# OPTIONS_GHC -fno-warn-orphans #-}
to the top of your file.
-Brent
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
Thanks a lot for the detailed explanation. I read about it before but it wasn't clear enough for me; I still miss some common understanding and experience with type classes. The goods news are that it's very interesting and fun to get this experience :) For Data.Vector, I guess this is a design choice not to provide the Num instance. I can think of several approaches with or without bounds check for example. The (*) function can have different meanings: elementwise multiplication, vector product, etc. The idea is to build all the tools for the library I'm working on, i.e. users are unlikely to make other Num instances. Having the compiler work for me is something I get used to with Haskell, so I fully agree with you. I hoped more compilers in other languages were thought so well. Thanks again for the help. Adrien On 06/02/2012 17:40, Brent Yorgey wrote:
The concept is simple: an orphan instance is an instance
instance Class Type ...
which is in neither the module where Class is declared, nor the module where Type is declared. In your case, both 'Num' and 'Data.Vector' are defined elsewhere. One reason you might not want this is because many people might define identical or similar instances for the same types, so if/when that instance is actually added to the module defining the type or class in question it will break a lot of code. But in my mind this is not an argument *against* orphan instances but rather an argument *for* contributing instances back upstream (which is certainly a good idea when it makes sense). For example if you think the Num instance for Data.Vector is something that would be generally useful you can submit a patch to the Data.Vector maintainer, and then delete the instance from your module when a new version of Data.Vector is released.
However, sometimes there are good reasons not to do this -- for example if (say) the implementation of the Num instance for Data.Vector relied on some *other* package and it was desirable not to add this other package as a dependency for Data.Vector.
I seem to recall there is also something about GHC having to do more work for orphan instances, but I don't recall the details. And I am not sure why I should have to change my code to save GHC some work -- I want *GHC* to work harder to save *me* work, not the other way around.
-Brent
On Mon, Feb 06, 2012 at 04:25:05PM +0100, Adrien Haxaire wrote:
Thank you.
It will save me some time, and I will be happy using the nice API of Data.Vector without having to wrap everything.
I will still read more on orphan instances to be sure I understand the concept and the consequences, even if now I know they are minor for me.
Adrien
On Mon, 6 Feb 2012 08:53:14 -0500, Brent Yorgey wrote:
Yes: don't bother. Having an orphan instance is really not that big of a deal. And it's certainly not worth making a newtype just to avoid the warning. If you want to turn off the warning you can add
{-# OPTIONS_GHC -fno-warn-orphans #-}
to the top of your file.
-Brent
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
participants (2)
-
Adrien Haxaire -
Brent Yorgey