[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Test for procedure?
>In article <email@example.com.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
> > (operation? (lambda nil nil))
> > (procedure? (lambda nil nil))
>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.
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 (make-microcode 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?