home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / function / 957 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  2.2 KB
  1. Path: sparky!uunet!mcsun!uknet!mucs!m1!sewardj
  2. From: sewardj@cs.man.ac.uk (Julian Seward (DRL PhD))
  3. Newsgroups: comp.lang.functional
  4. Subject: Re: programs that are too lazy
  5. Message-ID: <SEWARDJ.92Jul26232657@r6.cs.man.ac.uk>
  6. Date: 26 Jul 92 22:26:57 GMT
  7. References: <BEVAN.92Jul26184420@panda.cs.man.ac.uk>
  8. Sender: news@cs.man.ac.uk
  9. Organization: Department of Computer Science, University of Manchester
  10. Lines: 45
  11. In-reply-to: bevan@cs.man.ac.uk's message of 26 Jul 92 17:44:20 GMT
  12.  
  13.  
  14. Steven J Bevan writes:
  15.  
  16. | This works well, and keeps the usage down to under 2Mb for the input
  17. | that previously ran out of heap.  However, there are a couple of
  18. | things that bother me about this :-
  19. | 
  20. | 1. The extra amount of work that has to be done in "forcing" the store.
  21. |    This bumps up the runtime.
  22.  
  23. Hmm ... but not by much.
  24.  
  25. | 2. A simple, one-liner using higher order functions has turned into a
  26. |    10 line tail recursive loop.  Now being a Schemer at heart, I have
  27. |    no particular problem with this, but it does seem to go against the
  28. |    whole idea of "higher order functions are good" which most fp books
  29. |    espouse.
  30.  
  31. I have a couple of comments on this.  Firstly, the problem
  32. is you are getting 000's of thunks.  The problem is *not*
  33. the use of a higher-order function.  Even if you unfolded the
  34. definition of "foldl" at the parameterisation shown, the program would
  35. behave the same.
  36.  
  37. Secondly, a few minutes of investigation and a few changed lines
  38. made a massive difference to the usability of the program. 
  39. In my book this is a very small price to pay for the
  40. convenience of a language as expressive as Haskell.  I believe
  41. a few (say five at most) strategically placed hyperstrictnesses (so to speak)
  42. can make a big difference to the space behaviour of programs 
  43. tens of thousands of lines long.  Using a heap-profiling
  44. compiler, it is easy to spot the functions filling the heap up
  45. with thunks.
  46.  
  47. For this reason, I believe the Haskell committee should
  48. consider the provision of two built-in functions:
  49.  
  50.    hyperstrict, whnf :: Eq a => a -> b -> b
  51.  
  52. both of which evaluate their first argument (fully or to whnf)
  53. and return the second.  We can simulate this at the moment using
  54. Haskell 1.2, but it might be more efficient if compilers could
  55. regard these as primitive.
  56.  
  57. Jules
  58.