Test for procedure?

[mark@mcc.com (Mark Scheevel)]

>In article <28600@yale-celray.yale.UUCP>, @MC.LCS.MIT.EDU,@MCC writes:
>> Is there a finer-grained test for procedure values than PROCEDURE? ?
>> As it stands, PROCEDURE? answers true to both procedures and
>> operations (and any other object that can be applied).  We need to be
>> able to distinguish actual, honest-to-goodness closures created by
>> LAMBDA from these other apply-able entities
>
>The predicate OPERATION? will let you distinguish operations from everything
>else:
>
>    > (operation? (lambda nil nil))
>    ()
>    > (procedure? (lambda nil nil))
>    #T
>
>However, you should normally not need to rely on this distinction.  There is
>probably a better way to do what you need to do.  For example, if you're
>trying to distinguish closures that you create for some purpose from other
>procedure-like objects lying around, you might create objects instead that
>answer #t to a special predicate.
>
>-- Ashwin.

As is usually the problem in cases like this, I was being sloppy.
We're implementing a different system on top of T, and I wanted to use
T operations to represent our operations, and T procedures to
represent what amount to microcode for the new system.  This is just
sloppy design, and I should make a clear distinction between these new
entities and all previously existing ones.  In particular, as David
and Ashwin have pointed out, given that I want to directly invoke
these "microcode" objects but still be able to identify them, I
should do something like

	(define-predicate microcode?)
	(define (make-microcode closure)
	  (object closure
	   ((microcode? self) t)))
	...
	(define microcode-add (make-microcode add))

This will allow me to invoke these things with sufficiently little
overhead that I should quit worrying about it.

Thanks for the kick in the pants:-)

By the way, does T3.1 include the fix for proper handling (i.e., no
stack buildup) of tail-recursive operation invocation?

--Mark