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. Results of Bug Report (David Webster)
2. Changing evalList to parList creates a space leak?
(Travis Erdman)
3. Re: instances of different kinds (Greg)
4. Re: Results of Bug Report (Daniel Fischer)
----------------------------------------------------------------------
Message: 1
Date: Sat, 28 Aug 2010 19:47:18 -0700
From: David Webster <[email protected]>
Subject: [Haskell-beginners] Results of Bug Report
To: Haskell Beginer <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I submitted a bug report to Haskell-Platform a few days ago. The ticket was
assigned an owner who accepted it. How will I know if the problem has been
corrected?
David Webster
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20100828/855cbf91/attachment-0001.html
------------------------------
Message: 2
Date: Sat, 28 Aug 2010 22:19:49 -0700 (PDT)
From: Travis Erdman <[email protected]>
Subject: [Haskell-beginners] Changing evalList to parList creates a
space leak?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Ok, since I last visited, as a result of the help from contributors on this
list, I've reached a nice spot. The serial implementation of my processing
algorithm works quite quickly (including the tree pruning that I mentioned last
time) and the space leaks have been eliminated without resort to the dreadful
foldl'rnf.
Here are simplified versions of key components of my program:
data Tree a = Node a [Tree a]
calcTree :: Tree MyData -> InputData -> Tree MyData
calcTree (Node cargo subtrees) input = Node (process cargo input)
recurseChildren
where
process a b = ....
recurseChildren = map (\t -> calcTree t input) subtrees `using` evalList
rseq
newTree = foldl' calcTree starttree (take n inputdatalist)
The <`using` evalList rseq> term at the end of recurseChildren was key to
solving a space leak without resorting to foldl'rnf (which is a performance
killer). This is also the place in my code where it makes the most sense to
introduce some parallelism (ie to traverse the subtrees in parallel).
However, when I simply change the evalList to a parList, a space leak is
created anew, which I didn't anticipate at all. (of course, I also made the
change of compiling with -threaded and -feager-blackholing flags ... but if I
compile with those flags and leave it as evalList, there is no space leak).
I'm using parallel-3.1.0.0, so it's not the space leak from parallel-1.1.x.
Any ideas why this simple change should introduce a space leak? How might I
get to where I want to go?
thanks again,
Travis
------------------------------
Message: 3
Date: Sun, 29 Aug 2010 03:23:29 -0700
From: Greg <[email protected]>
Subject: Re: [Haskell-beginners] instances of different kinds
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Aug 28, 2010, at 8:04 AM, Brandon S Allbery KF8NH wrote:
>> I think what you're saying is that not only can an instance do no less than
>> the class has guaranteed, it can do no *more*-- meaning the instance can't
>> further restrict the return type even if that return type still conforms to
>> the class definition. In this case returning a Float breaks the class
>> contract because I've gone and said what type of Floating type will be
>> returned.
>
> Another way of thinking about this, btw, is that when you use a typeclass
> function the only things "visible" about the type are the things defined by
> the class; so if the instance wants to do something different, there's no
> way to enforce it. Think of it as a mechanical translator that can
> faithfully translate specific phrases that it knows about but garbles
> anything else.
>
>> The class definition doesn't mean "div2pi can return any type of Floating
>> value", it means "div2pi *will* return any type of floating value".
>
> More precisely, it means that when something invokes div2pi, it has the
> right to request any type of floating value at its sole discretion. But the
> instance says "nuh-uh, you get the same type you feed it, nothing else".
On Aug 28, 2010, at 5:11 AM, Jürgen Doser wrote:
> I would say it like this: div2pi does not return a type of Floating
> value of its own choosing, it is able to return every type of Floating
> value (the concrete type is then chosen by the context in each case
> where div2pi is used).
>>
And here is the "a-ha" moment! I've been looking at return types as values
"pushed" from the functions, but they are in fact "pulled" by the caller. That
makes a lot of sense in the functional paradigm of Haskell, but it didn't click
how this relates to the type system. In an imperative language like C, the
function declares what it is going to return, and the caller is responsible for
dealing with it. In Haskell, the function is more of a transformation applied
to its inputs and the caller requests that a value of a certain type be
returned. The class definition gives the range of choices available.
Thank you both.
Also, Jürgen, thank you for the worked example you provided. It runs just fine
on my side as well and gives me something to toy with:
On Aug 28, 2010, at 5:11 AM, Jürgen Doser wrote:
> This works:
>
> data Foo a = Foo a deriving Show
>
> x :: Float
> x= 5.6
>
> y :: Foo Double
> y= Foo 9.8
>
> class TwoPi a where
> div2pi :: (Floating b) => a -> b
>
> instance (Real a, Floating a) => TwoPi (Foo a) where
> div2pi (Foo a) = realToFrac a / (2*pi)
>
> instance TwoPi Float where
> div2pi a = realToFrac a / (2*pi)
>
> main = print ((x,y),(div2pi x, div2pi y))
>
> *Main> main
> ((5.6,Foo 9.8),(0.8912676661364157,1.5597184423005745))
>
>>
> The (Real a) restriction in the instance definition for Foo a is
> necessary. If a would be Complex Double, for example, there is no way
> you can sensibly expect a Float return value.
>>
> Jürgen
------------------------------
Message: 4
Date: Sun, 29 Aug 2010 13:29:27 +0200
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] Results of Bug Report
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Sunday 29 August 2010 04:47:18, David Webster wrote:
> I submitted a bug report to Haskell-Platform a few days ago. The ticket
> was assigned an owner who accepted it. How will I know if the problem
> has been corrected?
>
> David Webster
If HP bug tracker is like the GHC trac, you should automatically be emailed
when the ticket is changed - if you've submitted the ticket from an account
with a valid email address.
Otherwise, add your address to the cc list to be mailed automatically.
Or you could periodically check the ticket for changes if you don't want to
give your address away.
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 26, Issue 56
*****************************************
