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: Num instnace for [Double] (Ben Gamari)
2. Re: confusing type signature with sections (Patrick Redmond)
3. Re: confusing type signature with sections (Keshav Kini)
4. Re: Defaulting the following constraint .... (Alan Buxton)
5. Re: Defaulting the following constraint .... (Brandon Allbery)
----------------------------------------------------------------------
Message: 1
Date: Thu, 03 Oct 2013 09:38:36 -0400
From: Ben Gamari <[email protected]>
To: Nathan H?sken <[email protected]>
Cc: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Num instnace for [Double]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Nathan H?sken <[email protected]> writes:
> Hey
> Thanks for the answer one thing to discuss remains for me:
> With applicative I could add TimeSeries like this:
>
> print $ (+) <$> pure 4 <*> times
> (+) <$> times1 <*> times2
>
> ok .. but actually I find that (for this case) clumpsy.
> I would much prefer to write times1 + times2 (especially in complex cases):
>
> (times1 + times2)/(times3 * times4)
>
> Don't you agree? Or do I oversee something?
>
I admit that applicative notation isn't quite as convenient as working
with arithmetic expressions. As I've said in the past, overloading Num
isn't terribly desireable as you'll pretty much need to resign
yourself to partial implementations of some of the class members. A
middle path would be to instead define your own combinators for the
operations you need. For instance,
%+% :: Num a => TimeSeries a -> TimeSeries a -> TimeSeries a
%+% a b = (+) <$> a <*> b
%*% :: Num a => TimeSeries a -> TimeSeries a -> TimeSeries a
%*% a b = (*) <$> a <*> b
...
For at least some of these you could (ab)use the additive group classes
provided by vector-space[1] and linear[2] although there's no such class
for point-wise multiplication.
Cheers,
- Ben
[1]
http://hackage.haskell.org/package/vector-space-0.7.1/docs/Data-AdditiveGroup.html
[2] http://hackage.haskell.org/package/linear-1.3/docs/Linear-Vector.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20131003/16458353/attachment-0001.sig>
------------------------------
Message: 2
Date: Thu, 3 Oct 2013 10:57:25 -0400
From: Patrick Redmond <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] confusing type signature with
sections
Message-ID:
<CAHUea4HXQv=q8NV-t=VX3CxfYzL9e2x4B+-UK_Z0hu5kdSR=z...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Thank you both!
> The key is that typeclasses are open. You could write a Fractional instance
> for (a -> a), in which case it would be possible to do _something_ with this
> code. Would it be useful? Even Haskell can't guarantee that.
Yes, this is important! Thanks.
> Now, because we are writing ((+ 1) / 2) and we know that (/) takes two
> arguments that must be of the same type, we know that the type (Num a')
> => a' -> a' and the type (Num a'') => a'' have to be the same type, so
> it must be that a' = a -> a, so now we have:
>
> (+ 1) :: (Num a, Num (a -> a)) => a -> a
> 2 :: (Num a, Num (a -> a)) => a -> a
I'm still a little confused here. How can passing "2" into "(+ 1) /"
cause its type to be mangled? "2" has a type "(Num a) => a". How can
the presence of "(+ 1)" force the type of "2" to suddenly accept an
argument? How come it doesn't happen the other way around? (Meaning
"2" forces the type of "(+ 1)" to become simply "(Num a) => a".)
Prelude> :t 2 / (+ 1)
2 / (+ 1) :: (Fractional (a -> a), Num a) => a -> a
Thank you,
Patrick
------------------------------
Message: 3
Date: Thu, 03 Oct 2013 10:04:34 -0500
From: Keshav Kini <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] confusing type signature with
sections
Message-ID: <[email protected]>
Content-Type: text/plain
Patrick Redmond <[email protected]> writes:
> Thank you both!
>
>> The key is that typeclasses are open. You could write a Fractional instance
>> for (a -> a), in which case it would be possible to do _something_ with this
>> code. Would it be useful? Even Haskell can't guarantee that.
>
> Yes, this is important! Thanks.
>
>> Now, because we are writing ((+ 1) / 2) and we know that (/) takes two
>> arguments that must be of the same type, we know that the type (Num a')
>> => a' -> a' and the type (Num a'') => a'' have to be the same type, so
>> it must be that a' = a -> a, so now we have:
>>
>> (+ 1) :: (Num a, Num (a -> a)) => a -> a
>> 2 :: (Num a, Num (a -> a)) => a -> a
>
> I'm still a little confused here. How can passing "2" into "(+ 1) /"
> cause its type to be mangled? "2" has a type "(Num a) => a". How can
> the presence of "(+ 1)" force the type of "2" to suddenly accept an
> argument? How come it doesn't happen the other way around? (Meaning
> "2" forces the type of "(+ 1)" to become simply "(Num a) => a".)
Remember that in type signatures, "a" represents *any* type. And one
example of a type that "a" can be is "b -> c", i.e. a function. The
type isn't being mangled, it's being refined -- more information is
being added. The type "a" doesn't say anything about arguments -- a
value of type "a" might be a function, or it might not be. A value of
type "a -> a" is definitely a function, so something has been learned
about the type. And you can't go the other way (making (+ 1) go from
type "a -> a" to just type "a") because that's throwing away
information.
-Keshav
------------------------------
Message: 4
Date: Thu, 3 Oct 2013 18:52:43 +0100
From: "Alan Buxton" <[email protected]>
To: "'The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell'" <[email protected]>
Subject: Re: [Haskell-beginners] Defaulting the following constraint
....
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks for the help. I now have another question related to this.
When I write:
isInt :: Double -> Bool
isInt x = x == fromInteger (floor x)
niceShow :: Double -> String
niceShow x = if isInt x then show (floor x :: Int) else show x
I get a warning about a "too strict if". If I then follow the recommendation
and change niceShow to be
show (if isInt x then (floor x :: Int) else x)
Then I get an error that Couldn't match expected type `Int' with actual type
`Double' which makes sense because floor x :: Int produces an Int but x
alone is a Double. Surely hlint could have figured this out from the type
signatures and not made the recommendation to change my if structure?
What's going on here? And what best to do? What is a "too strict if" anyway?
a
From: Beginners [mailto:[email protected]] On Behalf Of David
McBride
Sent: 30 September 2013 21:54
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell
Subject: Re: [Haskell-beginners] Defaulting the following constraint ....
It is because you do a floor on x, returning a where a is an Integral, but
which Integral is it? Is it an Int or an Integer? Well it decides to
default it to integer because that is what ghci does as it is the safe
option, but it decided to warn you about it just so you are aware. Afterall
integers are slower than ints, and you might have wanted an int. You can
silence the warning by telling it what to do:
niceShow x = if (isInt x) then show (floor x :: Int) else show x
niceShow x = if (isInt x) then show (floor x :: Integer) else show x
On Mon, Sep 30, 2013 at 4:06 PM, Alan Buxton <[email protected]> wrote:
Hi
I have something like this - purpose is that I need to drop redundant .0 in
a whole number - so to show 1.2345 as 1.2345 and to show 1.0 as 1
module Test where
niceShow x = if (isInt x) then show (floor x) else show x
isInt x = x == fromInteger (floor x)
But the hlint in my vim plugin keeps warning me that
test.hs|3 col 38 warning| Defaulting the following constraint(s) to type
`Integer'
|| (Integral a0) arising from a use of `floor' at
/tmp/test.hs:3:38-42
|| (Show a0) arising from a use of `show' at /tmp/test.hs:3:32-35
|| In the first argument of `show', namely `(floor x)'
|| In the expression: show (floor x)
|| In the expression: if (isInt x) then show (floor x) else show x
What does this mean? And what would I need to do in order to prevent this
warning?
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20131003/7664d0f0/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 3 Oct 2013 14:33:25 -0400
From: Brandon Allbery <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Defaulting the following constraint
....
Message-ID:
<cakfcl4x1tybdn4x4msyu5juodeglxq2lft90t2xobyz2+4k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Oct 3, 2013 at 1:52 PM, Alan Buxton <[email protected]> wrote:
> niceShow x = if isInt x then show (floor x :: Int) else show x
>
> ** **
>
> I get a warning about a ?too strict if?. If I then follow the
> recommendation and change niceShow to be****
>
> ** **
>
> show (if isInt x then (floor x :: Int) else x)****
>
> ** **
>
> Then I get an error that *Couldn't match expected type `Int' with actual
> type `Double'* which makes sense because floor x :: Int produces an Int
> but x alone is a Double. Surely hlint could have figured this out from the
> type signatures and not made the recommendation to change my if structure?
> ****
>
> **
>
hlint doesn't recognize types, only code structure to some extent (it is a
parser, not a compiler). As such, it will sometimes produce bad advice like
that.
"Too strict if" pretty much means what you saw... that you have the same
structure in both legs and it thinks you should abstract it out. But, as I
noted, it doesn't know about types so it can't recognize that you can't
type the refactored expression. In fact I'd generally claim that "Too
strict if" is by far its worst designed diagnostic, because of its
inability to recognize types and because the resulting message is
incomprehensible.
In short, take hlint's diagnostics with several grains of salt.
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20131003/3b5a075f/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 64, Issue 7
****************************************
