I took a minute to look at what you were doing before crashing. Overall I gots to say you are coming up to speed on Lisp, macros, and Cells very nicely. :) The bad news is that I am not going to look too losely unless you yell for help, I gotta start getting ready for ECLM and the small matter of shipping my damn app. :)

(defmd web-apropos (page) (term (c? (param? "term"))) (pkg (c? (param? "pkg"))) (exported-only-p (c? (let ((rslt (param? "EXPORTED-ONLY-P"))) (trc "exported" rslt) rslt))) (filter (c? (param? "filter"))) (result (c? (progn (trc "calculating result" (^term) (^pkg) (^exported-only-p) (^filter)) (bwhen (search (^term)) (apropos-list search (^pkg) (^exported-only-p)))))) (title "Lisp Apropos") (style "style.css") (kids (c? (the-kids (mk-div () (mk-form (:action "get") (mk-label (:for "term") "Apropos: ") (mk-input (:name "term" :id "term" :-type "text" :value (c? (term (u^ web-apropos)))))

(mk-checkbox "Exported: " exported-only-p)

(mk-text (c? (exported-only-p (u^ web-apropos))))

(mk-div (:id :result) (mk-ul () (list (loop for match in (result (u^ web-apropos)) collect (let ((match match)) (mk-li () (mk-text match)))))))))))))

I just wanted to mention that once we implement XREF (object identity) this last rule for the kids can look like this:

(loop for match in (result (u^ web-apropos)) collect (let ((m match)) (or (find m .cache :key 'value) (mk-li (:value m) (mk-text (value .parent))))))

[Note btw that by this time all the mk-whatevers will be returning the OID, not the xhtml. And I am sure I am messing things up. <g> I do a lot of self-clarification as I code. <g>]

The idea above is that there is a symbol-macro .cache (I think it is a symbol macro) that evaluates to the value calculated by the rule the last time, nil if there was no last time. So it is pretty easy to avoid regenerating the same kids.

We could go even further and have one slot that takes the union of the cache and any new items that need to be created, while the kids slot then takes what it needs from that slot. That way if they winnow the list too much and then unwinnow all the xhtml will already exist.

And once we do Cells/js, damn, it all can happen on the client side. Which raises the question of whether we love Parenscript. If not, hey, this is Lisp, we never use anyone else's code, we'll do our own.

What I am envisioning is something like Franz's implementation of Prolog. We start in CL, then say (prolog... and now we are doing prolog, in the middle of which we can say (lisp... and do a computation in Lisp.

I'd love to see rules default to server-side, but be able to say (client... blah blah stuff that needs to xlate to JS and cells-js and then possibly within that (server ... and now we are making a trip to the server to get some info.

What would be scary would be to be able to some compiler-style analysis and determine the above automatically at run-time without requiring the developer to stop and think about which side of the broadband should be doing the job.

kt