Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Newtype to avoid orphans (Brent Yorgey)
2. Re: Newtype to avoid orphans (Adrien Haxaire)
3. Re: Newtype to avoid orphans (Brent Yorgey)
4. Re: Is foldr slow? (Zhi-Qiang Lei)
5. Re: Newtype to avoid orphans (Adrien Haxaire)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Feb 2012 08:53:14 -0500
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] Newtype to avoid orphans
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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
------------------------------
Message: 2
Date: Mon, 06 Feb 2012 16:25:05 +0100
From: Adrien Haxaire <[email protected]>
Subject: Re: [Haskell-beginners] Newtype to avoid orphans
To: <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 3
Date: Mon, 6 Feb 2012 11:40:33 -0500
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] Newtype to avoid orphans
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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
> >[email protected]
> >http://www.haskell.org/mailman/listinfo/beginners
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 4
Date: Tue, 7 Feb 2012 00:42:09 +0800
From: Zhi-Qiang Lei <[email protected]>
Subject: Re: [Haskell-beginners] Is foldr slow?
To: Daniel Fischer <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Appreciate. That's favorable to understand recursion in Haskell.
On Feb 5, 2012, at 9:25 PM, Daniel Fischer wrote:
> On Sunday 05 February 2012, 11:33:35, Zhi-Qiang Lei wrote:
>> Thank you very much. You are right. foldl performs much better here. I
>> thought foldr always has a performance advantage due to its tail
>> recursion.
>
> Firstly, tail recursion isn't automatically better in Haskell. Due to
> laziness, the evaluation sequence is different from what it'd be in eager
> languages, and not necessarily the order in which the steps are written in
> the code.
>
> If the recursive call to a (non tail-recursive) function is in a lazy
> argument position of the result, a lot of evaluation can take place before
> the recursive call is demanded.
>
> A tail recursive function on the other hand cannot deliver any part of the
> result before the recursion is completed.
>
> Secondly, foldr is not tail recursive, foldl is:
>
> foldr f z (x:xs) = x `f` (foldr f z xs)
>
> foldl f z (x:xs) = foldl f (f z x) xs
>
> Thus if 'f' is lazy in its second argument, like for example (++), the
> result can be partially delivered before the recursive call, in
>
> x ++ (foldr (++) [] xs)
>
> the whole list x has to be evaluated before the evaluation of foldr takes
> its next step.
>
> But if 'f' is strict in its second argument, like for example (+) on Int,
> the recursive call has to be evaluated before the top level call to 'f' can
> be evaluated, so a stack of function calls has to be built before any
> evaluation of an 'f'-call can start, and that stack has to be unwound
> during the evaluation of the 'f'-calls from the innermost to the outermost.
> That gives you two traversals: build stack, unwind.
>
> In such cases, tail recursion (a left fold) is better because then the call
> to 'f' can be evaluated before the recursive call - but it has to be
> forced, or it will generate a thunk ((...(z `f` x1) ... ) `f` xn-1) `f` xn
> (and when that thunk is finally evaluated it nuilds a stack of 'f'-calls,
> which is then unwound, so you get three traversals: build thunk, thunk ->
> stack, unwind - unless 'f' is lazy in its first argument, like flip (++),
> then the thunk may be consumed without building the stack).
Best regards,
Zhi-Qiang Lei
[email protected]
------------------------------
Message: 5
Date: Mon, 06 Feb 2012 19:55:46 +0100
From: Adrien Haxaire <[email protected]>
Subject: Re: [Haskell-beginners] Newtype to avoid orphans
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
>>> [email protected]
>>> http://www.haskell.org/mailman/listinfo/beginners
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 44, Issue 9
****************************************
