🚀 go-pugleaf

In <BxJ39L.LCv@mentor.cc.purdue.edu>, hrubin@mentor.cc.purdue.edu (Herman Rubin) wrote:
> In article <mwm.2lit@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
> >> You need explicit pointers to functions when the caller does not know
> >> the name of the function being called, but the caller has received a
> >> pointer to the function.
> 
> >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. In C-oid style, this would be:
> 
> 		..............................
> 
> I found this difficult to read, and it does not seem that it handles
> the situation I envision.

Herman Rubin finding something difficult to read? That's amazing,
considering what you call "obvious" code. Maybe it's the lack of
extraneous characters that serve little or no useful purpose.

> The way that I would want to use pointers
> would be to have fl as the pointer to a fill function, and des as the
> pointer to a descriptor array, of which the first two arguments would
> be pointers to the current element of the buffer and the bounding position,
> and then when it is needed make sure that the current element is correct,
> and issue the call
> 
> 	*fl(*des);

No problem. That call would look like:

	fl(*des) ;

> I will consider any suggestions to do this in a better manner, but I
> am not willing to make it any less flexible, nor to put any more burdens
> on the writers of the subprogram, nor of the (usually separately compiled)
> fill functions.

You want to make it better? Two things you can do. First, throw away
the silly attachment to pointers per se, and let the compiler handle
the trivia. When you call a function with a function as an argument,
you give it the name of the function as the argument. When you receive
a function as an argument, you declare it - AND USE IT - as a
function. That means you can drop the extra "*" on the call, and on
the reference to the function in the call. No explicit pointers
needed; they are all implicit, and might not be there at all,
depending on how good your compiler is.

The net result of this change is to _remove_ a burden from the
programmer of the fill functions. They no longer have to remember
which functions are locally declared functions, and which are things
that are being passed in from outside. They are all functions, and can
be used as such.

Second, don't use pointers to code, use closures (which can be done
with the above in place). That's a pair of pointers; one to a piece of
code, and one to the environment the code is supposed to run in. This
allows you to use the same piece of code with local "static" data,
except every "instance" has it's own copy of the static data. If you
think of it as an object in an OO system, you won't be very far wrong.
I'm not going to try and express this in a C-like notation.

	<mike