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). kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application