🚀 go-pugleaf

In article <721539019@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>: 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);

I still do not think that this catches the problem.  I did not use des
for the buffer; des is a short array or struct which contains the global
information on the location and status of the buffer.  With pointers, it
would contain the location of the next available item and the bound to
decide when to refill.  It would also contain, although the calling 
program might not know it, enough additional information for the fill
program to operate, possibly including the references to fill subroutines
and buffer descriptors which it would need to reference.  In the use of
the buffer, one only needs the access information, while refilling would
need more.

>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.

But how does the hardware do it efficiently?  Probably with pointers, 
because the hardware only calls by reference.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)