home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / function / 964 < prev    next >
Encoding:
Text File  |  1992-07-27  |  4.1 KB  |  83 lines

  1. Newsgroups: comp.lang.functional
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!newstand.syr.edu!polar
  3. From: polar@top.cis.syr.edu (Polar Humenn)
  4. Subject: Re: ** LAZY LANGUAGES FASTER?? **
  5. Message-ID: <1992Jul27.123947.1536@newstand.syr.edu>
  6. Organization: Syracuse University, CIS Dept.
  7. References: <1992Jul24.134857.23289@gdstech.grumman.com> <3737@svin02.info.win.tue.nl>
  8. Date: Mon, 27 Jul 92 12:39:47 EDT
  9. Lines: 72
  10.  
  11. In article <3737@svin02.info.win.tue.nl> erik@win.tue.nl writes:
  12. >david@gdstech.grumman.com (David Nettles) writes:
  13. >
  14. >Lazy evaluation does indeed save time by not evaluating arguments
  15. >that are not needed. However, eager evaluation saves times by never
  16. >evaluating the same argument twice.
  17. >
  18. >In eager languages, all arguments are evaluated ONCE, regardless of
  19. >whether they are actually needed.
  20. >
  21. >In lazy languages, an argument is evaluated once for every time that it 
  22. >is used. If the argument is used N times, it will be evaluated N times. 
  23. >So if the argument is not used, it will not be evaluated,
  24. >   if the argument is used once, it will be evaluated once,
  25. >   if the argument is used twice, it will be evaluated *TWICE*, etc.
  26.  
  27. Exuse me, I see your point, however, I don't really know of a *better*
  28. lazy evaluator that doesn't take advantage of formal arguments that
  29. are shared, and updates where necessary when the argument is finally evaluated.
  30.  
  31. There was a little problem with your example, However.
  32. >  (\x.\y.xx)AB which reduces to AA which reduces to aa
  33.    Assuming that A==>a
  34. However, if indeed lazy evaluation then you have.
  35.     (\x . \y x x) A B ==> AA  ==> aA  
  36. To go any further "a" would have to engulf "A" and force its evaluation,
  37. Just a making a lazy point.
  38.  
  39. Anyway, very naive lambda calculus evaluators may operate the way you assume, 
  40. but most are implemented with an environment, in which uses of a variable
  41. point to its environment entry.  Once evaluated, the environment entry(ies) are
  42. updated to reflect the evaluation throughout.  Therefore, arguments that are
  43. shared are evaluated only once, not twice, three times, etc.
  44.  
  45. IMHO, however, lazy evaluation is not a god that will do us *great* benefit.
  46. Instead, I believe it is a useful tool in applications where it works
  47. best.  For example when expressing a problem with infinite data structures, 
  48. and possible _L avoidance is concise.   (That post showing an implementation
  49. of lazy lists in SML was a good argument in this favor)
  50.     
  51. In the same light, Prolog is a good language where Left-to-right resolution 
  52. and unification fits the problem best. Adding other things (which everybody
  53. complains about) slows it down, or doesn't work well.
  54. SML (aside from the appauling syntax) is a good
  55. language where need for eager evaluation fits the problem well.
  56. Ie. if you need a screwdriver, don't reach for the hammer or the vice-grips.
  57.  
  58. Of course, one of our biggest problems, is that we *think* we need standards,
  59.    (and of course, we have and are developing *many* of them ;-) 
  60. We all would feel more comfortable if we can do everything in one language.
  61. Its sort of like pulling off the highway into the McDonalds in North Carolina
  62. knowing that you can still get the same burger you got in South Dakota.
  63. It's comforting.
  64. However, I think PL/1 is a good example of where this philosophy 
  65. has lead us in the past.
  66.  
  67. Personally, I think there will and should always be new languages solving 
  68. specific problems, good tools.  This argument of whether or not lazy evaluation 
  69. is better than eager evaluation is horse hockey.  People are always picking some
  70. eager evaluation problem that has appauling lazy behavior, like matrix
  71. multipication, obviously a problem suited better for eager evaluation and
  72. updatable arrays --ie. handing the nail to the guy with the vice grips.
  73.  
  74. And the lazy advocates are always picking that damn ((\x\y.y) _L A) example --
  75. Handing the screw to the guy with the wrench.  
  76.  
  77. One of these days, we will learn to integrate all these tools, methods, 
  78. evaluation strategies so that we use the proper ones for the problem(s)
  79. at hand. Instead of always trying to invent more "general-purpose" wheels.
  80.  
  81. Later,
  82. -Polar
  83.