🚀 go-pugleaf

In article <1991Jan29.153549.19220@spool.cs.wisc.edu>, 
quale@picard.cs.wisc.edu (Douglas E. Quale) writes about a response of mine
to a challenge of his:
> 
> Sorry, this doesn't work because compose returns a structure, not a function.
> 
> Suppose I want to use the library function twalk(3c).
> It takes a function as an argument.  Will it accept the output of your
> compose, or do I have to rewrite every library function that takes functional
> parameters to provide two versions?

First of all, I concede!  Like I said, why pick on C?  The poor thing has
been knocked to the ground, she's out for the count, and you're still
beating on her!  C does not have first-class composable functions!
We've established that, and I think people realize that it can be a real
limitation.

But it can do second-class functionoids that do a lot, if not everything.

For instance, to answer your question,

   struct Func *globalFuncPtr;

   <return type> globalFuncInterface ( <args> )
      <arg declarations>;
      {
      return apply( globalFuncPtr, <args> );
      }

   ...

   globalFuncPtr = compose( ... );
   twalk( ...globalFuncInterface, ... );

Yes, this is kind of messy.  (For one thing, it's not recursive: the 
functionoid in globalFuncPtr had better not try the same trick.)  If 
you're trying to hand composed functions to library functions in every 
other line of your code, it's going to be very messy.  

I'm just saying there's a large area of application of these
functionoids that doesn't run into the kind of problems you've been
pointing out, or does rarely enough that you can patch your way through.

--Steve Witham
Not-the-fault-of: SMDS, Inc., Concord, MA