home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3650 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  3.8 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!agate!stanford.edu!rutgers!news.columbia.edu!psinntp!psinntp!dg-rtp!sheol!throopw
  2. From: throopw@sheol.UUCP (Wayne Throop)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Pointers
  5. Summary: notation can be abstract or concrete, but not practical to be both
  6. Message-ID: <721626972@sheol.UUCP>
  7. Date: 13 Nov 92 01:08:31 GMT
  8. References: <BxJzzv.4H7@mentor.cc.purdue.edu> <721539019@sheol.UUCP> <BxLyv1.CG4@mentor.cc.purdue.edu>
  9. Lines: 67
  10.  
  11. : From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  12. : Message-ID: <BxLyv1.CG4@mentor.cc.purdue.edu>
  13. : I still do not think that this catches the problem.  I did not use des
  14. : for the buffer; des is a short array or struct which contains the global
  15. : information on the location and status of the buffer.
  16.  
  17. The difference between this and what I presented is trivial.  Simply
  18. have des be a structure containing dope information and a reference to
  19. the buffer, rather than a reference to such a structure.  Or however
  20. else you want to lay it out.
  21.  
  22. :: You might claim that "reference" (or "ref") is just "pointer" spelled
  23. :: sideways, but there is no "address of" operation, no "indirect"
  24. :: operation, and hence no EXPLICIT pointer operations at all in the
  25. :: language.
  26. : But how does the hardware do it efficiently?  Probably with pointers,
  27. : because the hardware only calls by reference.
  28.  
  29. This is a change in subject.  The subject was, for several postings
  30. now, to question whether EXPLICIT pointers are required in the
  31. LANGUAGE, not whether some implementation of that language might 
  32. employ pointers.
  33.  
  34. The notion of "reference" captures the notion of pointer fairly
  35. exactly.  The difference is, it does it implicitly rather than
  36. explicitly, and the indirections needed are explicated at the
  37. definition point instead of at every use point.
  38.  
  39. How the hardware might best do this is irrelevant to this point.  I
  40. doubt anybody ever seriously claimed that current, practical *hardware*
  41. need not have pointers, any more than anybody in their right mind would
  42. claim that current, practical hardware could/should do without branch
  43. instructions.
  44.  
  45. At this point, many people may be saying "potAYto, potAHto, I say it's
  46. just equivalent to a pointer!".  But remember, a turing machine
  47. notation is "equivalent" to a lambda calculus, but I wouldn't want to
  48. use the former to reason about computability.  Roman numerals are
  49. "equivalent" arabic notation, but I wouldn't want to do arithmetic 
  50. with the former.  And "reference" notations are better than
  51. "pointer" notations in the specific ways I've already described.
  52.  
  53.  
  54. The bottom line is, do you want a notation to describe the abstract,
  55. essential features of the computation you want to do, or a notation to
  56. describe the concrete, incidental features of the computation as
  57. realized on particular hardware?  It is essentially impossible to do
  58. both near-perfectly at the same time.  And from what I understand, the
  59. concrete and incidental features are more important to Herman, because
  60. there is where the last gasp of efficiency is to be had.
  61.  
  62. Traditionally, such notations are called "assembly languages".
  63. If you need one, you need one, and NO high-level notation is
  64. going to help you.
  65.  
  66. That said, I'll agree that it is desirable that high-level notations be
  67. able to seamlessly integrate with low-level notations.  For example,
  68. allowing for inline insertion of assembly instructions.  But this is by
  69. no means a trivial problem, it is inherrently unportable (and thus has
  70. very high cost-per-customer), and simply put, the marketplace doesn't
  71. support such features, because needing to squeeze the last two (or even
  72. ten) percent of speed out of a program is a narrow, niche market.  It
  73. is VERY rare that low-level notations need to be more tightly
  74. integrated than with a procedure-call interface, so it just
  75. doesn't pay vendors to provide this.
  76. --
  77. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  78.