home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3610 < prev    next >
Encoding:
Text File  |  1992-11-12  |  3.6 KB  |  90 lines
  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!umn.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Subject: Re: Pointers
  5. Message-ID: <BxLyv1.CG4@mentor.cc.purdue.edu>
  6. Sender: news@mentor.cc.purdue.edu (USENET News)
  7. Organization: Purdue University Statistics Department
  8. References: <BxJzzv.4H7@mentor.cc.purdue.edu> <721539019@sheol.UUCP>
  9. Date: Thu, 12 Nov 1992 14:57:00 GMT
  10. Lines: 78
  11.  
  12. In article <721539019@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
  13. >: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  14. >: Message-ID: <BxJzzv.4H7@mentor.cc.purdue.edu>
  15. >:: No, you don't need *explicit* pointers to functions. It's perfectly
  16. >:: reasonable (and I would argue, preferable) to allow function names
  17. >:: in argument lists.
  18. >: The function is not an argument to something else.  I do not see how
  19. >: the code will run any better if we have to use something like
  20.  
  21. >:         superfill(*fl,*des)
  22.  
  23. >: than what I have suggested.  All superfill would do is to call *fl,
  24. >: after putting more stuff on the stack, and do some more stack management.
  25. >: So just as many pointers are used, anyhow.
  26.  
  27. >But explicit pointers are not required in any event.  So you want to
  28. >bind a variable name to a function globally, as a side effect, instead
  29. >of within the scope of some procedure: fine, let there be procedure
  30. >*variables* in addition to procedure arguments.  See, ma?  No
  31. >explicit pointers.
  32.  
  33. >Of course, in C, there is no such notion, but if we treat
  34.  
  35. >          void (*functionname)(buffertype*);
  36. >          extern void actualfunction(buffertype*);
  37. >          buffertype* buffername;
  38. >          extern buffertype actualbuffer[];
  39.  
  40. >as a quaint way of saying 
  41.  
  42. >          variable functionname:   procedure(buffertype),
  43. >                   buffername:     reference buffertype;
  44. >          external actualfunction: procedure(buffertype),
  45. >                   actualbuffer:   buffertype;
  46.  
  47. >Then we can simply say things like this, in either C or the
  48. >hypothesized language without explicit pointers:
  49.  
  50. >          functionname = actualfunction;
  51. >          buffername = actualbuffer;
  52. >          [...]
  53. >          functionname(buffer);
  54.  
  55. >(or, if short names are wanted)
  56.  
  57. >          var fl:    proc(buf_t),
  58. >              des:   ref buf_t;
  59. >          ext func:  proc(buf_t),
  60. >              buf:   buf_t;
  61. >          [...]
  62. >          fl = func;
  63. >          des = buf;
  64. >          [...]
  65. >          fl(des);
  66.  
  67. I still do not think that this catches the problem.  I did not use des
  68. for the buffer; des is a short array or struct which contains the global
  69. information on the location and status of the buffer.  With pointers, it
  70. would contain the location of the next available item and the bound to
  71. decide when to refill.  It would also contain, although the calling 
  72. program might not know it, enough additional information for the fill
  73. program to operate, possibly including the references to fill subroutines
  74. and buffer descriptors which it would need to reference.  In the use of
  75. the buffer, one only needs the access information, while refilling would
  76. need more.
  77.  
  78. >You might claim that "reference" (or "ref") is just "pointer" spelled
  79. >sideways, but there is no "address of" operation, no "indirect"
  80. >operation, and hence no EXPLICIT pointer operations at all in the
  81. >language.
  82.  
  83. But how does the hardware do it efficiently?  Probably with pointers, 
  84. because the hardware only calls by reference.
  85. -- 
  86. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  87. Phone: (317)494-6054
  88. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  89. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  90.