home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / scheme / 1978 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  4.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!ucbvax!bloom-beacon!INTERNET!dont-send-mail-to-path-lines
  2. From: jeff@aiai.edinburgh.ac.UK (Jeff Dalton)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Abelson&Sussman; Lisp vs C in Compilers/Prog. Lang class; etc.
  5. Message-ID: <10523.9207271828@subnode.aiai.ed.ac.uk>
  6. Date: 27 Jul 92 18:28:07 GMT
  7. Sender: daemon@athena.mit.edu (Mr Background)
  8. Organization: The Internet
  9. Lines: 87
  10.  
  11. > Date: Thu, 23 Jul 1992 20:09:58 GMT
  12. > From: "Mark C. Carroll" <carroll@hercules.cis.udel.edu>
  13.  
  14. > >> Date: 16 Jul 92 20:36:04 GMT
  15. > >> From: "Mark C. Carroll" <carroll@hercules.cis.udel.edu>
  16.  
  17. > >> For writing a system like a compiler, I find that the overwhelming
  18. > >> majority of errors that I tend to make are captured by the ML
  19. > >> typechecker, so that when I finally get a module to typecheck, that
  20. > >> module works perfectly. (For more general types of programming,
  21. > >> typechecking will catch some, but not all bugs. But as I said, in a
  22. > >> compiler, the kind of errors that people seem to make are almost
  23. > >> always revealed during the typecheck.)
  24. > >
  25. > >Note that you've gone from "some people (like me)" and "the majority
  26. > >of errors I make" to "in a compiler ... the kind of errors people seem
  27. > >to make".
  28. > >
  29. > >But I've just been working on some compilers, and type checking
  30. > >wouldn't have helped _me_ very much (at least not this time), so
  31. > >I have some doubts about your generalization.
  32.  
  33. > Well.. first, have you ever worked with an ML-like type system?
  34. >
  35. > If you're only typing experience is with Pascal/Ada, then you're
  36. > certainly going to think that typing systems are not useful in a
  37. > compiler. But the SML type system is very different... 
  38.  
  39. I am not anything like an expert on ML, but I have used it some
  40. and I do know something about it.  In particular, I know more or
  41. less what kind of type inference and checking it does and that
  42. it is different (and IMHO much better) than Pascal/Ada.
  43.  
  44. I find it easy to believe that some people find the ML type system a
  45. tremendous help in writing compilers and moreover find that it has
  46. few, if any, disadvantages.  I'd find it a help too, but I think
  47. languages like ML have some disadvantages.  So, on balance and all
  48. things considered, I am happier with Lisp.  (But I've already posted
  49. enough on that topic, I think.)
  50.  
  51. I do make type errors, but (1) they tend to be fairly easy to find,
  52. and (2) most of them are can be caught by simple name and arity
  53. checks.  Lisp compilers are usually capable of performing these
  54. checks.
  55.  
  56. Another thing to bear in mind is that as soon as you start using
  57. CLOS or some other object system you get type checking for free.
  58. Ok, it's run-time type checking (in most cases), but since method
  59. lookup happens at run-time anyway, and since the type error is
  60. just "no applicable method", the checking does not involve any
  61. additional efficiency cost.
  62.  
  63. Of course, you have to do some testing to find these errors,
  64. since they (typically) won't be caught at compile-time.  But
  65. a compiler will have a fairly comprehensive test suite anyway,
  66. and in Lisp it's often pretty easy to test changes by just
  67. typing in a test case.
  68.  
  69. > In a compiler, the typical errors seem to come from abusing the data
  70. > structures - things like performing some kind of manipulation of the
  71. > parse tree on a parse tree node where it's innappropriate, or
  72. > inconsistencies in the handling of the intermediate form accross
  73. > different constructs, etc.
  74.  
  75. So far as I can recall, I haven't had much trouble with errors of
  76. that sort.  Except for trivial errors, most of them are things like
  77. generating the wrong code or clearing the record of register use
  78. at the wrong point.  But perhaps thare a lot of errors that I hardly
  79. notice that would be caught more easily by type checking.  I suppose
  80. it's possible.
  81.  
  82. One reason that abusing data structures seems rare may be that Lisp
  83. programs tend to be data-driven in the sense that what-to-do is
  84. determined by some property of the data such as its type.  Object-
  85. oriented programming is an example.  
  86.  
  87. > In effect, for a compiler type project, typing becomes almost a system
  88. > of checked assertions insuring that calls are consistent. 
  89.  
  90. The would certainly bne useful, but it seems to be something that
  91. I can get by without.
  92.  
  93. Perhaps the people on this list who have written Lisp or Scheme
  94. compilers have kept track of their bugs and can say what their
  95. experience has been?
  96.  
  97. -- jeff
  98.