Capability patterns prescribe passing capabilities as parameters to a called function, (callee herein). Less often they prescribe revoking (or rescinding) those capabilities after the return from the callee. The capability in question is to the object herein. When should they prescribe revocation?

Generally it would be good to revoke after each call except for those cases where the agreed contract is for the callee to retain the capability for use subsequent to the call. Every capability system that I know imposes some extra cost to such revocation however and I consider here some situations where there is little or no advantage to revocation.

It is first necessary to try to enumerate the cases where the caller might be harmed by subsequent invocation to the capability. This enumeration may be incomplete.

In many situations it is possible to fabricate a narrower capability dynamically at the call site. In several languages I can write something such as
callee([j, v | j<1000 ifTrue ob[j] <- v])
callee((INT j, VAL v)VOID: IF j<1000 THEN on[j] := v FI)
(callee (lambda (j v) (if (< j 1000) (vector-set! ob j v))))
In each case the capability to an anonymous procedure is passed to enable the callee to modify any of the first 1000 entries of array ob. In Keykos this was fairly easy to do but only by some one with detailed knowledge of the low-level assembly language mechanisms.

In some systems transient capabilities may exist which are produced by the call primitive and revoked by the return primitive, but such capabilities are another sort of animal; task switching must me somehow permitted to preserve these over scheduling events. Different sorts of capabilities are a large architectural expense. In the Algol68 case the procedure value passed is just such a transient value. For Scheme and Smalltalk the callee might retain the ability to modify ob after the return.