I am struck by the possibility that if Rees's SEAL operation accepted a unique object pointer (cons cell would be fine) as an argument, and if the corresponding UNSEAL demanded presentation of the same cons cell pointer, that the operation itself would need to be implemented in privileged code but the sealing tool would not need to be defended from general use. We had a parallel discussion about this in context of the process tool, and concluded at that time that the process tool itself did not require protection.
Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595
I have been here before. This is one of those cases where some idea was so obvious that writing it down didn't seem fruitful. Here is a pattern for Scheme that builds sibling communication upon seals which, in turn, can be built on eq?:
See <http://www.mediacity.com/~norm/CapTheory/Amplify.html> for general rights amplification starting from just eq?. Rees's seal operation, made primitive, would make the performance OK.
I will try to dress up the notes tomorrow. The code runs in MacGambit. Error casses are, as usual, not handled well. Norman Hardy <http://www.mediacity.com/~norm>