home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / function / 1366 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  3.3 KB
  1. Path: sparky!uunet!snorkelwacker.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: Is efficient backtracking feasible in functional languages?
  5. Date: 13 Nov 92 17:31:52
  6. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  7.     Perceptive)
  8. Lines: 71
  9. Message-ID: <TMB.92Nov13173152@arolla.idiap.ch>
  10. References: <TMB.92Nov12122350@arolla.idiap.ch> <1992Nov12.162725.25836@cs.yale.edu>
  11. Reply-To: tmb@idiap.ch
  12. NNTP-Posting-Host: arolla.idiap.ch
  13. In-reply-to: jones-mark@CS.YALE.EDU's message of Thu, 12 Nov 1992 16:27:25 GMT
  14.  
  15. In article <1992Nov12.162725.25836@cs.yale.edu> jones-mark@CS.YALE.EDU (Mark P. Jones) writes:
  16.  
  17.    |  In general, in a lazy language, you are often at the mercy of the
  18.    |  compiler to prove things about your code in order to obtain decent
  19.    |  performance.
  20.  
  21.    But in a lazy language, you don't need to do a lot of the standard
  22.    optimisations like tail recursion elimination, moving constants outside
  23.    loops etc.  Laziness gets you those things for free! [...]
  24.  
  25.    |  Fortunately, in SML, you have better control over
  26.    |  resources than in a lazy language,
  27.  
  28.    Unfortunately, you will often have to write extra code to control
  29.    those resources...
  30.  
  31.    Yes, it is true that reasoning about the resources used by a program
  32.    in a lazy language is more difficult than reasoning about a program in
  33.    a strict language like SML.  But sometimes it's nice to be able to write
  34.    code using a list without wondering whether I ought to write it with an
  35.    explicit loop, or whether I should use a stream library instead, or ...
  36.    I'm not criticising SML.  But Haskell (and lazy languages in general)
  37.    have their nice points too.
  38.  
  39. I completely agree that a lot of the mess in writing programs comes
  40. from orchestrating what gets computed when, and that it would be nice
  41. to leave all that to the compiler. However, resource constraints mean
  42. that I need more control than lazy languages currently give me, and,
  43. as I mentioned before, I somehow remain doubtful that
  44. compilers/runtime systems be able to make the right tradeoffs between
  45. space and time in the near future.
  46.  
  47. I'd rather see a little more support added to eager languages for
  48. lazyness and caching. In SML, you can already define many lazy
  49. constructs like streams, thunks, and caches. Some improvements that
  50. I would like to see are:
  51.  
  52.     * eliminate those weak type variables that come from
  53.           the underlying imperative implementations
  54.  
  55.     * provide versions that use structural equality, hashing,
  56.       and comparisons (SML has polymorphic "=", but for some
  57.       obscure reason does not provide polymorphic "<" and
  58.       polymorphic "hash" to go with it)
  59.  
  60.     * make the syntax a little nicer; maybe I could declare
  61.       individual function arguments to be "lazy":
  62.  
  63.       fun f(x: 'a lazy) = [x]
  64.       f(3+4) --> [thunk] : int lazy list
  65.  
  66.     * provide "dynamic contexts" for caching:
  67.  
  68.       fun f(x) = ...
  69.  
  70.       fun g() =
  71.           let
  72.           (* any call to "f" within this dynamic scope
  73.               is cached; the cache gets destroyed when this
  74.           dynamic context exits *)
  75.  
  76.                   dynamically_cache(f)
  77.                   ...
  78.           in
  79.           ...
  80.           end
  81.  
  82. Anyway, just some suggestions (actually, you can experiment with such
  83. constructs relatively nicely in CommonLisp or in Scheme with macros).
  84.  
  85.                     Thomas.
  86.