🚀 go-pugleaf

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <BxJzzv.4H7@mentor.cc.purdue.edu>
:: No, you don't need *explicit* pointers to functions. It's perfectly
:: reasonable (and I would argue, preferable) to allow function names
:: in argument lists.
: The function is not an argument to something else.  I do not see how
: the code will run any better if we have to use something like
: 
:         superfill(*fl,*des)
: 
: than what I have suggested.  All superfill would do is to call *fl,
: after putting more stuff on the stack, and do some more stack management.
: So just as many pointers are used, anyhow.

But explicit pointers are not required in any event.  So you want to
bind a variable name to a function globally, as a side effect, instead
of within the scope of some procedure: fine, let there be procedure
*variables* in addition to procedure arguments.  See, ma?  No
explicit pointers.

Of course, in C, there is no such notion, but if we treat

          void (*functionname)(buffertype*);
          extern void actualfunction(buffertype*);
          buffertype* buffername;
          extern buffertype actualbuffer[];
          
as a quaint way of saying 

          variable functionname:   procedure(buffertype),
                   buffername:     reference buffertype;
          external actualfunction: procedure(buffertype),
                   actualbuffer:   buffertype;

Then we can simply say things like this, in either C or the
hypothesized language without explicit pointers:

          functionname = actualfunction;
          buffername = actualbuffer;
          [...]
          functionname(buffer);

(or, if short names are wanted)

          var fl:    proc(buf_t),
              des:   ref buf_t;
          ext func:  proc(buf_t),
              buf:   buf_t;
          [...]
          fl = func;
          des = buf;
          [...]
          fl(des);

You might claim that "reference" (or "ref") is just "pointer" spelled
sideways, but there is no "address of" operation, no "indirect"
operation, and hence no EXPLICIT pointer operations at all in the
language.

In value-oriented languages like lisp, things are done differently
than the above variable-oriented methods.  But even so, even in lisp
(arguably a pointer-bashing language if ever there was one), there
are no explicit pointers, nor need of them.  (In fact, the lack of
explicit pointers in lisp makes it easier to pull space-saving tricks
like cdr-coding, I expect.)

: There is no reason why the caller needs to know the NAME of the function,
: in any case.  It is quite possible that even the object code might have
: elided the name.  This is even more the case when the program under which
: the caller is operating may want to change things at run time.

There is also no reason why the caller needs to EXPLICITLY INDIRECT the
reference to the function.  This form of referential transparency makes
it much easier to change the declaration of a statically bound
buffer-fill function, and go to a dynamically bound scheme, without
having to change all the places where the definition is referenced.  Or
vice versa: back out of a dynamically bound scheme to save the extra
pointer indirect that it implies, if the funcall is that
time-critical.

Of course, referential transparency as a general principle is far out of
fashion these days, despite C++'s addition of the "&" reference
declarator.  Of course, people make an exception for the cases of
generic and method binding; THOSE seem very much in fashion. 
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw