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.
Regards,
Duane Johnson
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),
then
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
file,
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
2001,
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).
Claus
PS. Perhaps these days, someone should rewrite the log viewer
in Canvas+JavaScript as a more lightweight and modern platform.
It also helps the general adoption cause, having Haskell more visible
and accessible.
claus.reinke:
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
out.
Btw, this is kind of relative strictness (when is one part of my
program
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
display).
If you have Java on your machines, try installing GHood [1] (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 [2], so
you could try the applet version instead, and in section 4.2 of
the paper [3] (as a "well known strictness problem";-). Page and
paper
mention a few other similar examples and discuss some differences
between static (which parts are needed at all) and dynamic
strictness
(which parts are needed when, relative to other demands).
Claus
[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GHood
[2] http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/GHood
[3] http://www.cs.kent.ac.uk/~cr3/publications/GHood.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
