home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / function / 1015 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.4 KB
  1. Path: sparky!uunet!pipex!unipalm!uknet!mcsun!sunic!liuida!henni
  2. From: henni@ida.liu.se (Henrik Nilsson)
  3. Newsgroups: comp.lang.functional
  4. Subject: Algorithmic Debugging for Lazy Functional Languages
  5. Message-ID: <1992Aug19.133753.7451@ida.liu.se>
  6. Date: 19 Aug 92 13:37:53 GMT
  7. References: <1992Jul12.061122.8943@eng.umd.edu>     <NICKH.92Jul14151920@VOILA.VENARI.CS.CMU.EDU>     <1992Jul14.205627.25659@eng.umd.edu>     <DELACOUR.92Jul14152041@waxwing.parc.xerox.com> <SCHIEX.92Aug18143749@jupiter.cert.fr>
  8. Sender: news@ida.liu.se
  9. Organization: CIS Dept, Univ of Linkoping, Sweden
  10. Lines: 45
  11.  
  12. schiex@cert.fr (Thomas Schiex) writes:
  13.  
  14. [examples illustrating the usefulness of laziness deleted]
  15.  
  16. >All these GOOD thing have too be payed in terms of time (small overhead, so
  17. >small it is negligible). But the main issue is DEBUGGING which is very
  18. >difficult. Sequencing is completly disturbed and the poor human is lost when
  19. >tracing ! (obvious relations with concurrent processing). However some
  20. >papers gives interesting debugging issues for lazy languages (for Daisy, see
  21. >"Lisp and symbolic computations", in the first numbers).
  22.  
  23. Our group has been involved in research on algorithmic debugging for some time
  24. and recently we have applied this technique to lazy functional languages with
  25. some success. However, several difficult problems remain to be solved before
  26. this can be regared as a practical approach.
  27.  
  28. In algorithmic debugging, the program to be debugged is first executed and a
  29. complete execution trace tree is built at the procedure/function level. This
  30. tree is then searched top-down for the procedure/function invocation that
  31. caused the entire program to misbehave, and once this invocation is found it
  32. is concluded that the bug is inside the corresponding procedure/function.
  33. The user must aid the debugger in this search by answering questions regarding
  34. whether or not invocations behaved correctly. Thus the user need not concern 
  35. himself with operational aspects such as execution order but can concentrate
  36. on the declarative semantics of the program instead.
  37.  
  38. I'm going to present a paper on this topic at PLILP'92 next week and I'll be
  39. happy to e-mail copies (postscript) of it to anyone who is interested.
  40.  
  41.  
  42.  
  43. -- 
  44.  
  45. Henrik Nilsson (henni@ida.liu.se)
  46. Department of Computer and Information Science
  47. Linkoping University
  48. S-581 83 Linkoping
  49. Sweden
  50. --
  51.  
  52. Henrik Nilsson (henni@ida.liu.se)
  53. Department of Computer and Information Science
  54. Linkoping University
  55. S-581 83 Linkoping
  56. Sweden
  57.