[Haskell-cafe] Re: A guess on stack-overflows - thunksbuild-upand
duane.johnson at gmail.com
Fri Mar 20 21:19:06 EDT 2009
I just found out about GHood through this thread, and since it
impressed me very much to see something so cool, I feel bad making
this comment... but I am always disturbed by the flickering effect
produced by java applets in my browser (FF 3.0) while scrolling. From
an implementation standpoint this is obviously a nitpick, but from a
designer standpoint it nearly single-handedly kills any prospect of my
putting it up on a page.
With that said, I think the canvas+js idea is a wonderful alternative
to proprietary Flash.
On Mar 20, 2009, at 5:36 PM, Claus Reinke wrote:
>> It would be great to have a video of this in action up on youtube.
>> You can simply 'recordmydesktop' on linux (and likely elsewhere),
>> upload the result.
> I'm curious: how would a non-interactive animation running in Flash
> in a browser be better than an interactive animation running in Java
> in a browser?-) When I wrote GHood (many years ago), I explicitly
> looked into the applet option, in the hope that people would use it
> to document and discuss observation logs of their favourite Haskell
> strictness issues, with animations available on their web pages, right
> next to the discussions.
> That hasn't happened yet (the only users I was aware of were the
> DrHylo/Pointless Haskell project), but I just checked, the old .jar
> the source of which hasn't been perused for a long time, still
> worked in applet mode (in Opera, a browser I didn't know about in
> using a Java Runtime several versions removed from that time - try
> that in Haskell.. ;-), straight from that old project page (which
> also explains how to set such things up), so anyone could add
> animations of their favourite examples on their web-pages. But don't
> let that keep you or anyone else from addressing the youtube
> audience (one could add audio explanations, I guess).
> PS. Perhaps these days, someone should rewrite the log viewer
>> It also helps the general adoption cause, having Haskell more visible
>> and accessible.
>>>>> The problem occurs when the result value is needed and thus
>>>>> the thunks need to be reduced, starting with the outermost,
>>>>> which can't be reduced without reducing the next one .... etc
>>>>> and it's these reduction steps that are pushed on the stack
>>>>> until its size cause a stack-overflow.
>>>> Yes, that's exactly right, and something that's not often pointed
>>> Btw, this is kind of relative strictness (when is one part of my
>>> needed to answer demands on another part) is the kind of example
>>> for which old GHood can be helpful (once you get used to the
>>> If you have Java on your machines, try installing GHood  (on
>>> hackage thanks to Hugo Pacheco), then things like
>>> ghc -e ':m +Debug.Observe' -e 'printO $ observe "foldr" foldr (+)
>>> 0 [1..4] '
>>> ghc -e ':m +Debug.Observe' -e "printO $ observe \"foldl'\"
>>> foldl' (+) 0 [1..4] "
>>> ghc -e ':m +Debug.Observe' -e 'printO $ observe "foldl" foldl (+)
>>> 0 [1..4] '
>>> This was also among the examples on the GHood home page , so
>>> you could try the applet version instead, and in section 4.2 of
>>> the paper  (as a "well known strictness problem";-). Page and
>>> mention a few other similar examples and discuss some differences
>>> between static (which parts are needed at all) and dynamic
>>> (which parts are needed when, relative to other demands).
>>>  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GHood
>>>  http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/GHood
>>>  http://www.cs.kent.ac.uk/~cr3/publications/GHood.html
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe