home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3698 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  4.1 KB
  1. Path: sparky!uunet!pmafire!mica.inel.gov!ux1!news.byu.edu!eff!sol.ctr.columbia.edu!emory!wupost!darwin.sura.net!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!sunic!psinntp!psinntp!dg-rtp!sheol!throopw
  2. From: throopw@sheol.UUCP (Wayne Throop)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: languages which allow the introduction of new operators
  5. Message-ID: <721862492@sheol.UUCP>
  6. Date: 16 Nov 92 00:15:11 GMT
  7. References: <Bxr9vx.KBD@mentor.cc.purdue.edu> <Bxpr2J.JF7@mentor.cc.purdue.edu>
  8. Lines: 71
  9.  
  10. :: The fact that the language is conceptually
  11. :: stack based does *not* mean that it has *any* stack at runtime!
  12. : From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
  13. : Message-ID: <Bxr9vx.KBD@mentor.cc.purdue.edu>
  14. : This is the case if the considerations for the optimizer were put in by
  15. : the compiler writer.  Computers are extremely fast sub-imbeciles.  If we
  16. : had a group of compiler people who would do their best to incorporate
  17. : considerations which users see in their optimizers, and produce their
  18. : optimizers so that these improvements can be quickly inserted, we may
  19. : get reasonable results.
  20.  
  21. Yeah, right, it's all those lazy compiler people who just aren't doing
  22. their best.  Just like those lazy statisticians.  If we had a group of
  23. statisticians who would do their best to incorporate the statistical
  24. considerations which users actually see into their statistical models,
  25. and produce their models so that improvements can be quickly inserted,
  26. we might avoid all the misuses of statistics by poor, hard-working,
  27. long-suffering scientists in other fields.
  28.  
  29. Yeah, right.
  30.  
  31. : The semantic model of the language can, however, greatly inhibit the
  32. : programmer.  
  33.  
  34. True.  Just like all those nit-picky details they try to teach in
  35. statistics classes can inhibit a scientist's creativity with numbers. 
  36.  
  37. : Try communicating floating binary from one machine to
  38. : another; the only semi-portable way I have seen are to convert to
  39. : higher precision floating decimal, transmit that, and convert back.
  40.  
  41. And this problem is due to the "semantic model of the language?"
  42. Yeah, right.  I'm sure it has nothing to do with the binary format
  43. that the hardware architects of the two machines decided to implement.
  44.  
  45. ::: At the moment, you'd have to hack the Pop compiler to make this generate
  46. ::: in-line code. If there was a machine instruction to do the job, I should
  47. ::: imagine this might take the compiler-writer, oh, half-an-hour or so. 
  48. : From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
  49. : Message-ID: <Bxpr2J.JF7@mentor.cc.purdue.edu>
  50. : This should be a criticism of the way languages and compilers are produced.
  51. : The user of the language should be able to inline it quickly, with little
  52. : cooperation from the compiler.  And if the compiler-writer has to work so
  53. : hard, the design of the whole thing is atrocious.  
  54.  
  55. This is simply absurd.  Since it is the compiler's JOB to translate from
  56. a more abstract notation to a more concrete notation, the idea that
  57. changing the way this translation is done is done is feasible "with
  58. little cooperation from the compiler" is, at best, silly. 
  59.  
  60. I'm aware of compilers in which it would be the work of moments to
  61. insert a new optimization and recognize a new special case.  But if you
  62. really think that a "user" can simply slap in a new optimization
  63. quickly, *without* *breaking* *the* *compiler*, then again, this is at
  64. best, silly. 
  65.  
  66. The bottom line is, I've worked on compilers and optimizers.  I know at
  67. least some of the problems associated with schemes of allowing users to
  68. specify machine language sequences or new optimizations as part of the
  69. language notation.  To put it simply and bluntly, the problems are not
  70. trivial, and the reasons compiler writers don't often provide such
  71. features are not due to laziness or incompetence.  And I very much doubt
  72. that Herman's insisting on this insulting explanation for so many things
  73. he perceives wrong in compilers is going to be effective in bringing
  74. anybody around to his point of view. 
  75.  
  76. Now, maybe Herman isn't *intending* to be condescending and insulting. 
  77. But come ON.  "If we had a group of compiler people who would do their
  78. best [..to meet these needs of mine..]" indeed!
  79. --
  80. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  81.