home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3603 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.8 KB  |  97 lines
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!dg-rtp!sheol!throopw
  2. From: throopw@sheol.UUCP (Wayne Throop)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Pointers
  5. Summary: still don't need explicit pointers
  6. Message-ID: <721539019@sheol.UUCP>
  7. Date: 12 Nov 92 00:52:48 GMT
  8. References: <BxJzzv.4H7@mentor.cc.purdue.edu>
  9. Lines: 86
  10.  
  11. : From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  12. : Message-ID: <BxJzzv.4H7@mentor.cc.purdue.edu>
  13. :: No, you don't need *explicit* pointers to functions. It's perfectly
  14. :: reasonable (and I would argue, preferable) to allow function names
  15. :: in argument lists.
  16. : The function is not an argument to something else.  I do not see how
  17. : the code will run any better if we have to use something like
  18. : 
  19. :         superfill(*fl,*des)
  20. : 
  21. : than what I have suggested.  All superfill would do is to call *fl,
  22. : after putting more stuff on the stack, and do some more stack management.
  23. : So just as many pointers are used, anyhow.
  24.  
  25. But explicit pointers are not required in any event.  So you want to
  26. bind a variable name to a function globally, as a side effect, instead
  27. of within the scope of some procedure: fine, let there be procedure
  28. *variables* in addition to procedure arguments.  See, ma?  No
  29. explicit pointers.
  30.  
  31. Of course, in C, there is no such notion, but if we treat
  32.  
  33.           void (*functionname)(buffertype*);
  34.           extern void actualfunction(buffertype*);
  35.           buffertype* buffername;
  36.           extern buffertype actualbuffer[];
  37.           
  38. as a quaint way of saying 
  39.  
  40.           variable functionname:   procedure(buffertype),
  41.                    buffername:     reference buffertype;
  42.           external actualfunction: procedure(buffertype),
  43.                    actualbuffer:   buffertype;
  44.  
  45. Then we can simply say things like this, in either C or the
  46. hypothesized language without explicit pointers:
  47.  
  48.           functionname = actualfunction;
  49.           buffername = actualbuffer;
  50.           [...]
  51.           functionname(buffer);
  52.  
  53. (or, if short names are wanted)
  54.  
  55.           var fl:    proc(buf_t),
  56.               des:   ref buf_t;
  57.           ext func:  proc(buf_t),
  58.               buf:   buf_t;
  59.           [...]
  60.           fl = func;
  61.           des = buf;
  62.           [...]
  63.           fl(des);
  64.  
  65. You might claim that "reference" (or "ref") is just "pointer" spelled
  66. sideways, but there is no "address of" operation, no "indirect"
  67. operation, and hence no EXPLICIT pointer operations at all in the
  68. language.
  69.  
  70. In value-oriented languages like lisp, things are done differently
  71. than the above variable-oriented methods.  But even so, even in lisp
  72. (arguably a pointer-bashing language if ever there was one), there
  73. are no explicit pointers, nor need of them.  (In fact, the lack of
  74. explicit pointers in lisp makes it easier to pull space-saving tricks
  75. like cdr-coding, I expect.)
  76.  
  77. : There is no reason why the caller needs to know the NAME of the function,
  78. : in any case.  It is quite possible that even the object code might have
  79. : elided the name.  This is even more the case when the program under which
  80. : the caller is operating may want to change things at run time.
  81.  
  82. There is also no reason why the caller needs to EXPLICITLY INDIRECT the
  83. reference to the function.  This form of referential transparency makes
  84. it much easier to change the declaration of a statically bound
  85. buffer-fill function, and go to a dynamically bound scheme, without
  86. having to change all the places where the definition is referenced.  Or
  87. vice versa: back out of a dynamically bound scheme to save the extra
  88. pointer indirect that it implies, if the funcall is that
  89. time-critical.
  90.  
  91. Of course, referential transparency as a general principle is far out of
  92. fashion these days, despite C++'s addition of the "&" reference
  93. declarator.  Of course, people make an exception for the cases of
  94. generic and method binding; THOSE seem very much in fashion. 
  95. --
  96. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  97.