Kenny Tilton writes:
Thomas F. Burdick wrote:
Kenny Tilton writes:
On the other hand, Cells should not change Lisp unnecessarily.
It would be easy enough to do something such as (cv +unbound+) or just (cv) and then have the internal sm-install function invoke slot-makunbound instead of forcing the slot to be bound. Then one does not need a special test for cell-boundp (which sounds wrong anyway in re transparency).
But what about a rule that runs across an unbound cell/slot? I should think that does not generate an unbound error, rather the slot mediated by the rule should in turn be made unbound.
I guess echoing works OK, tho anyway doing this on the GUI slots will not get far since existing echos are not testing for unbounditude.
... I like this, because if you have rules that ultimately depend on an uncalculated value, you'll get an error when you try to ask for it.
Yes, I am thinking we throw a c-slot-unbound condition from the generated cell slot accessor. The internals code that kicks off a rule can trap for just that condition, so other non-cell unbound errors go splat normally. and user-level slot accesses would backtrace on c-slot-unbound. too bad there is no Lisp condition to be subclassed (guessing).
Heh, you missed it in my first message: unbound-slot.