home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / function / 970 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.1 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!destroyer!gumby!yale!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.functional
  4. Subject: Re: ** LAZY LANGUAGES FASTER?? **
  5. Message-ID: <TMB.92Jul28160101@arolla.idiap.ch>
  6. Date: 28 Jul 92 20:01:01 GMT
  7. References: <1992Jul24.134857.23289@gdstech.grumman.com> <3737@svin02.info.win.tue.nl>
  8.     <farrell.712286497@coral.cs.jcu.edu.au>
  9. Sender: news@ai.mit.edu
  10. Reply-To: tmb@idiap.ch
  11. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  12.     Perceptive)
  13. Lines: 32
  14. In-reply-to: farrell@coral.cs.jcu.edu.au's message of 28 Jul 92 01:21:37 GMT
  15.  
  16. In article <farrell.712286497@coral.cs.jcu.edu.au> farrell@coral.cs.jcu.edu.au (John Farrell) writes:
  17.  
  18.      *Non-strict* evaluation saves time by not evaluating arguments which are not
  19.    needed. *Lazy* evaluation saves time by evaluating each argument at most once.
  20.    Eager evaluation evaluates each argument exactly once.
  21.  
  22.      It is the mechanism by which lazy evaluation is implemented which slows it
  23.    down. The speedup due to not evaluating arguments is often negligible because
  24.    mostly people don't write functions which don't use their arguments.
  25.  
  26. I think there are two views towards strict evaluation in a purely
  27. functional framework:
  28.  
  29.  (1) it constrains the program, letting the compiler generate
  30.      better code (a constant factor speedup)
  31.  
  32.  (2) it affects the semantics of functions in the presence of
  33.      errors and non-termination
  34.  
  35. Mostly what I care about is (1). I care about (2) only when I am
  36. debugging. Therefore, for debugging, I want strict evaluation.  For
  37. using my code, I want the most efficient evaluation possible.
  38. Usually, I suspect that will be strict evaluation, but on parallel
  39. machines, it could be something else.
  40.  
  41. Altogether, it therefore seems prudent to write programs so that they
  42. depend as little as possible on whether the language is strict, eager,
  43. non-strict, or lazy. But if it came down to a choice, I'd suspect that
  44. eager evaluation is a practical necessity for many applications, and
  45. languages should provide it at least in some form.
  46.  
  47.                     Thomas.
  48.