home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / acorn / tech / 61 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  6.1 KB
  1. Path: sparky!uunet!wupost!waikato.ac.nz!bwc
  2. From: bwc@waikato.ac.nz (Ug!)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Re: New Language/Compiler (ideas wanted)
  5. Message-ID: <1992Aug19.173612.10221@waikato.ac.nz>
  6. Date: 19 Aug 92 17:36:12 +1200
  7. References: <1195@grun.is> <1992Aug17.132929.10141@waikato.ac.nz> <KERS.92Aug17083517@cdollin.hpl.hp.com> <1992Aug18.114418.10160@waikato.a <KERS.92Aug18090246@cdollin.hpl.hp.com>
  8. Organization: Vooniersity fo Kaiwato
  9. Lines: 141
  10.  
  11. Chris Dollin writes:
  12. >Ug! writes [responding to me]:
  13. > 
  14. >    Beware: Lisp is essentially an interpreter, even when it's compiled.
  15. > 
  16. > Would you like to explain the grounds on which you base this claim? [What do
  17. > you mean by ``essentially'' and ``interpreter''?]
  18.  
  19. Not really - I think you know what I mean.  I qualify Lisp as an interpreter,
  20. since much lisp code actually writes lisp programs which are then executed at
  21. some stage.  I also qualify Smalltalk as an interpreter though, so maybe I'm
  22. wrong.
  23.  
  24. >    > Lisp. Scheme. Poplog Pop11. Smalltalk. Don't forget ratios and complexes.
  25. > 
  26. >    Oh I know.  But ratios and complexes can be added where needed.  They 
  27. >    shouldn't be a 'standard part' of the language.  
  28. > 
  29. > I think the standard library *is* part of the language, and I'd rather have
  30. > ratios and complexes than not.
  31.  
  32. Ah, right!  In which case, by all means!  I try to distinguish between
  33. languages which are operator & type rich, and languages which are library
  34. rich.  Oberon is a classic example.  A minimalist language with a huge set
  35. of libraries.  Smalltalk is another good example.  However, if you view the
  36. standard libraries of a language as part of the language itself, then by all
  37. means add all of these things.
  38.  
  39. I was objecting to them being added as base types and so forth.  The Modula-2
  40. ISO workgroup added COMPLEX as a base type, which I think is rediculous!
  41.  
  42. > I suggested user-defined operators. Ug! said:
  43. > 
  44. >    Hmm.  Perhaps.  The problem then is that you have to pake allowances for
  45. >    all symbols and symbol combinations in the parser.  Tricky.  I'd go for
  46. >    simplicity, and just allow the built in operators to be overloaded.
  47. > 
  48. > Tricky? *Tricky*? TRICKY?
  49. > 
  50. > ``Trivial'' is the word I'd use. Lexical analysers clump up letters into
  51. > identifiers all the time; what's to stop them clumping up sign characters into
  52. > operator names? There is *no* problem here, despite what C++ language
  53. > designers may have tried to tell you. [They're stuck with supporting the
  54. > lexis of C, and wimped out on requiring whitespace for utterances such as
  55. > ``x+++y''.]
  56.  
  57. Read what I said again.  Was I talking about lexical analysis?  No.  I was
  58. talking about parsing.  Perhaps you feel user defined operators are trivial
  59. to parse; I don't agree.
  60.  
  61. > I said:
  62. > 
  63. >    > Lists. Sets. Hash tables (both content and address based).
  64. > 
  65. > Ug! said:
  66. > 
  67. >    Exactly.  All of these are implementable though.  
  68. > 
  69. > [Presumably he means on top of the language.] Yes, but see my remarks above
  70. > about the library. Hash tables (especially address-based ones) are possibly
  71. > the single most useful data structures ever invented.
  72.  
  73. By all means.  All of these (and more) should be in the libraries.
  74.  
  75. > I said:
  76. > 
  77. >    I'd vote *against* abstract data types and for a simple but powerful module
  78. >    structure...
  79. > 
  80. > Ug! said:
  81. > 
  82. >    The reason is reuseability.  You can fudge it by returning some sort of
  83. >    'handle' (usually an index into a list), but if you are going to return a 
  84. >    handle, why not return the object itself?  Yes,  OO gets around it.  I'm 
  85. >    not a fan of OO though.
  86. > 
  87. > I'd put the object in the heap and return its address -- a perfectly good
  88. > handle for the object. I suspect we're at cross-purposes here; what do ADTs
  89. > gain you in reusability that module scoping does not?
  90.  
  91. When you have to pass back some sort of handle to the user of a module: not
  92. internally to a module.  Like C's and Basic's file handles, for example.
  93.  
  94. > Ug! responds to my ``GARBAGE COLLECTION'':
  95. > 
  96. >    Ooo.  Garbage Collection.  Nice.  Still, a big hit in speed/performace,
  97. >    etc.  See Modula-3 (also has freely available ftp'able descriptions).
  98. > 
  99. > What big hit did you have in mind?
  100.  
  101. Garbage collection is fine, but it really does need hardware to support it.
  102. There has been a lot of work done on stopping the 'sudden hit' (i.e. the
  103. machine freezes while garbage collection takes place), which early versions
  104. of Lisp and Smalltalk suffered from.  Most of them however now require a
  105. steady percentage of the processors time in which to perform garbage
  106. collection.  Without hardware, this can be quite noticeable, especially as
  107. memory fills.  (from experience with Smalltalk)
  108.  
  109. >    For simplicities sake, however, I am often willing to forgo it.  But is is
  110. >    definately a nice idea.
  111. > 
  112. > For simplicitys sake, I'd put it in. I've written too much C, and handled my
  113. > own store allocation too often, to want to force the poor programmer to do it
  114. > themselves. 
  115.  
  116. Oh come on!  This is probably the first time this guy has implemented a
  117. programming language and you want him to put in grabage collection?!!!  Be
  118. reasonable!  Better to implement a language without garbage collection than
  119. get bogged down and not manage to implement it at all!
  120.  
  121. >    Modula-2 fundges a solution with local modules.  But in the case where
  122. >    A & B share X.  B & C share Y.
  123. >    ...ouch.  But it happens (all to commonly).  Some sort of explicit 
  124. >    inheritance control in this case would be nice.
  125. > 
  126. > What does it buy you? Use modules and put up with the fact that B can see X.
  127. > If necessary have the compiler tell you. The idea is nice, but in practice
  128. > it's just make-work for the programmer.
  129.  
  130. Data hiding gains you quite a bit.  Read some stuff on software engineering.
  131. Essentially its a quality assurance measure.
  132.  
  133. > Other things:
  134. >    initialised declarations;
  135.  
  136. Yes!  Good point!  I'd go one step further: typable constants, not just for
  137. initialisation.  (constant arrays and records are *so* useful in Modula-2)
  138.  
  139. > unassignable names (``constants'');
  140.  
  141. Yes.  Constants please!
  142.  
  143. > incremental compilation;
  144.  
  145. Maybe.
  146.  
  147. > first-class procedures; first-class everything; full lexical scoping.
  148.  
  149. Can you explain these a little more?  I'm not that familiar with Common Lisp
  150. or Scheme, I'm afraid.
  151.                             Ug!
  152.