Constant space infinite itteration ... solution?
Hi all, Ok, I've got the Farari out of the garage, in to gear, and even driven it slowly around the block, but every time I put my foot down it just stalls. I'm trying to write a non trivial gui in Haskell. At the moment I'm using Hugs, and rapidly coming to the conclusion that I should be using something else such as GHC. As I see it the problem is basically that of tail recursion removal or as David Bergman calls it "last call optimisation". Specifically: David Bergman wrote
It is easy to get the feeling that the recursive call in
recurse = do { f x ; recurse }
is the last one, but this is just an illusion of the iterative layout of "do". Sometimes the monads lure us into old iterative thought patterns...
Taking away the syntactic sugar, we end up with
recurse = f x >> recurse
This reveals the fact that there can be no last call optimization, because the last call is ">>".
In response Richard Uhtenwoldt echoed my own thoughts ...
What do you mean by this? Do you mean that that an implementation cannot execute arbitrarily many iterations/recursions of that last loop/definition in constant space?
And also said ...
If that's what you mean, you are wrong. GHC does that. The IO monad would be pretty damned useless for actual work if implementations did not do that!
So, my problem is that I find that my program crashes with "garbage collector can't collect enough memory" after about 64 Million output operations. What's really annoying is that I can write the whole thing *recursively* in C in a very "functional" manner, and it works just fine. As I see it the problem is that >> and >>= are functions and David is right about the "not the last call" problem. But, Richard is right that related optimisations should be possible in Haskell, and if not then you can kiss the whole load good by and go back to system programming in C. In particular I would claim that the definition: recurse = f x >>= recurse is essentially using >>= as a proxy temporal execution handler. So in the above definition the call to recurse *is* a "last-call", at least according to >>=. I'm probably saying that in a rather unorthodox manner, but I hope my basic intention is clear. In fact we can see >> in Haskell as rather kin to ; in C (Or perhaps it should be >>=, since ; does transfer the state to the subsequent computation). So, I've loaded GHC and I'm looking to use it instead (I expected to eventually anyway), but does this solve my problem? Or have I misunderstood something here? Also ... I've been using the graphics libs with HUGS, but I can't find the equivalent in GHC ... what is the recomended library for writing GUIs in GHC Haskell? And where do I get it? Thanks in advance ... Bruce (IIMS, Massey at Albany). ps: I've also been looking at Fudgets, but the code seems a bit cranky.
On Fri, 13 Dec 2002 11:41:23 +1300 b.i.mills@massey.ac.nz wrote:
I've got the Farari out of the garage
Ferrari (perhaps) ? ^___^ I am Italian I did a small program to find duplicates of .deb archives with older version, and it was impressingly fast if interpreted with ghci, and impressingly slow with hugs. Maybe we have to think of hugs as a "reference implementation". Vincenzo
I'm trying to write a non trivial gui in Haskell. At the moment I'm using Hugs, and rapidly coming to the conclusion that I should be using something else such as GHC.
I've written GUIs and other reactive systems with Hugs and GHC which did not leak space and, since the bulk of the work was done by X or Win32 (i.e., standard library code written in C), ran fast enough to keep up with humans. I doubt that GHC's speed and optimizations will fix your problems.
As I see it the problem is basically that of tail recursion removal or as David Bergman calls it "last call optimisation".
I suspect this may be a red herring. Space leaks in Haskell are most often caused by hanging onto unevaluated expressions or by accidentally hanging onto data that should be garbage. You should use a heap profiler to identify the true cause of your space leaks and then go fix those. GHC and NHC both contain good heap profilers. GHC contains libraries that are most similar to Hugs. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
b.i.mills@massey.ac.nz wrote:
Also ... I've been using the graphics libs with HUGS, but I can't find the equivalent in GHC ... what is the recomended library for writing GUIs in GHC Haskell? And where do I get it?
My current favourite way to make GUI's is to use the GUI painter Glade and have it generate C code with calls to the Gtk GUI library, after that the only thing you have to implement are the callbacks. One big advantage Gtk offers over other GUI libraries is that it clearly separates the GUI construction code from the callback code, this makes it very suitable for GUI painters, i.e. the code the GUI painter generates doesn't have to be changed manually. Another advantage of Gtk, from the Haskell viewpoint, is that it was designed to work with other languages. Quoted from the Gtk page: GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. Although I haven't looked at the Haskell side in a while, everything to go from Glade to a Haskell GUI should all be there: http://www.gtk.org/ http://glade.gnome.org/ http://www.cse.unsw.edu.au/~chak/haskell/gtk/ The most recent version of Gtk+HS has support for libglade, this means you can directly read the Glade XML file that describes the GUI construction and the names of the callback functions. To be honest I don't know how the callbacks are actually connected to Haskell code, but there is probably an example in the Gtk+HS distribution to show how it works. Jan
On Friday, December 13, 2002, at 05:06 PM, Jan Kort wrote:
Also ... I've been using the graphics libs with HUGS, but I can't find the equivalent in GHC ... what is the recomended library for writing GUIs in GHC Haskell? And where do I get it? <shameless advert> You may as well try Gtk2HS which is a binding to Haskell specifically for Gtk version 2. http://gtk2hs.sourceforge.net </shameless advert>
Or look on the Haskell home page under libraries. Axel.
participants (5)
-
Alastair Reid -
Axel Simon -
b.i.mills@massey.ac.nz -
Jan Kort -
Nick Name