GP lisper wrote:

I've been scratching my head and discovering how little I know about this lisp OO stuff. Got some books coming on interlibrary loan, but on-the-job training has worked in the past.

But I do know what idea I had in mind when I started this email exchange. So I would like to establish some common terminology, which makes it easier for me to read the code.

<snip terminology> ok, will adjust to your terms.

---

Comments on your old code:

... (defmodel ticker (model) ((ticker-sym :cell nil :initarg :ticker-sym :reader ticker-sym)

;; not a cell because I forgot that issues can change their ticker symbols <--Kenny ;; Not during a trading day. Because of 23.75 hour trading days, symbol changes ;; only occur on Friday afternoons. The index basket setup on Sunday is valid ;; thru the week. So should it be a cell then?

Your call. Simple issue: will a stock change symbol during the run of the application? I would add, "and will anyone care?". but assuming the thing is displayed, yeah, the text widget displaying the symbol will care. ie, some list will know only that it is displaying the stock object (or ticker object as you have now defined), the object being a Lisp instance with a slot which is the symbol. The list contents will not change, just the symbol associated with the listed ticker. So nothing tells the text label displaying the symbol to change, unless it is a cell and we can arrange for dataflow (aka "hey! you need to change the string in this text label and redraw it!".

(trades :reader trades :initform (c? (bwhen (xtrade (car (trades .parent))) (if (eql (ticker-sym self) (trade-ticker-sym xtrade)) (cons xtrade .cache) .cache)))) ;; the above could be done more efficiently, albeit less declaratively, by <--Kenny ;; making this an input cell (c-in nil) and having an output method on the ;; trades cell of the exchange push a new trade onto the trades cell of the ;; matching issue ;; ;; speed counts, there is (or will be) a LOT going on...

Yep, but my didactic instincts tell me to defer performance tweaks until you grok basic Cells.

...

; (defstruct trade ticker tickmin last) kennys previous

;; a trade never changes (well, we'll see) so for now it can just be a struct ;; changes are unimportant, the moving herd has stampeeded on

agreed. almost every time I am convinced something can be just a struct it ends up needing to be a DEFMODEL. But the change is trivial, so where I think I see a defstruct I use one.

---

I'm catching on a bit to this idea of spreading the code out amongst objects and methods, accessors and readers(? whatever stuffs values in). I smell wood burning!

You are almost ready to leave the temple, grasshopper. Cells are all about a declarative model which nicely chops up huge wodges of code into so many declarative cell rules. As I say in some of my doc, this is exactly what happens in spreadsheet programming: an emergent, complex financial model out of so many simple, discrete rules. Cells draw a developer into a natural, easy decomposition of complex state interactions into a declarative model of more or less simple rules. The only hard part is accepting that this is indeed possible. Surely this declarative thing must break down at some point. Nope. Back in the day someone proved that any GOTO program could be automatically be rewritten as a structured, GOTO-free program. I think we go thru the same epiphany when coming up to speed on Cells. After I first developed them, I certainly expected them to break down and not handle some requirement for many months. Only after throwing a variety of challenges at Cells did I conclude that there must be something deeply sensible about the critters.

kt