Lisp and software architecture
in [Lisp]
|
Prev: cosx - sinx + 3x2
Next: the Modernization of Emacs
From: goat_roperdillo on 12 Mar 2006 01:10 X-No-Archive:yes Ken Tilton wrote: > I see. You are weak at solving problems over the keyboard. Documentation > and re-documentation is the only way you can build interesting software. > As a consequence, all your code is documented, however slowly it is > produced. Your feature turns out to be a bug. I see. You are weak at solving problems by thinking. Hacking and re-hacking code randomly is the only way you can build software. As a consequence, none your code is documented, however slowly it is produced. Your bug turns out to be a feature. One such programmer was preparing a new system feature for a convention. While working late one evening he described his problem. I immediately recognized and explained the solution, a simple algebraic transformation requiring at most 20 LOC. But he was very poor at math and could not understand. Instead he worked an 80-hour week "changing the code until it works" (his words). He was still hacking code at the convention. He claimed to have succeeded just before the doors opened. When first hired he appeared to be an extremely hardworking individual. We soon realized he was little more than a human random code generator. Documentation written by such programmers is useless since they do not understand their code. > The Cells code /is/ my frickin documentation. (Just thought of that one. > <g>) You didn't have to say that - I'd recognized it before my first post on this thread. And that is all the more reason to carefully read the Cells "documentation." > That's my story and I am sticking to it. Ditto.
From: Ken Tilton on 12 Mar 2006 01:54 Tayssir John Gabbour wrote: > Ken Tilton wrote: > >>Tayssir John Gabbour wrote: >> >>>Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always >>>reporting NIL to me... >> >>That just happens to be the case, partly because it is a silly example, >>mostly because most of the slots are ephemeral, which are actually not >>the norm in real world programming. > > > Aaah, yes that makes sense. My understanding is that with discrete > processes, we basically have a choice between cells being T or > :ephemeral ("states" and "events"). > > And :delta seems to be absent from your sourcetree, which makes sense > too. That is either vestigial or will be resurrected if it ever comes up again. I honestly forget if I found :delta slots were obsoleted by synapses or closures or something, and it is too late to figure out now. The idea was to have, say, consecutive (setf (foo bar) 42) forms propagate each time, but then: (setf (foo bar) 0) ...not propagate at all. Kind of a second-order thang. This came up in a physics simulation, of a pendulum, IIRC. > > Do you think it would be an improvement to have :cell T by default, ? It is. Do you mean eliminate the :ephemeral alternative? I will guess yes based on the next: > and > if you want to cause an event, you'd do something other than setting > the slot-value? Like: > (setf (happens obj) :new-state) ;stays :new-state until changed > (eventf (happens obj) :new-event) ;reverts to initform immediately No. Eventhood (if you will) is an attribute of the slot, so the slot should always behave eventishly. :) Likewise outputs (ne echos, defined by def-c-output) are GFs specialized on the slot-name (and class and new and old values, but the point is that, unlike the rules one associates with a slot, they cannot be varied instance by instance. > > > Incidentally, if anyone could clarify a couple quick questions I'd be > grateful: > > * So, cells only update other cells in their own object instance (not > even cells allocated as :class)? No. And, not to quibble, I would say cells can depend on cells of any instance (so, yes, propagation (updating, as you say) can flow between cells of different instances). > Which means a cell in one object has > to explicitly set another object's c-in cell? You have been looking at the Cells-Gtk code, haven't you? :) SETFs of c-ins are rampant there. They are the equivalent of GOTOs, and largely defeat the declarative quality Cells provides. It is probably my fault. I used that trick to deal with circularities when in a weak moment i decided it was simpler than having a mechanism in Cells to deal with cycles. I do not think I will ever ban the trick outright, but I will always be looking for an excuse to do so. :) Cells3 at least forces one to wrap such behavior in a "mother, may I?" macro. > > * What other notable vars are there, like .cache and the ^slotnames? self, .cause (if that is still working <g>), and .parent, though the last two are just symbol macros you can track down. ken
From: Thomas F. Burdick on 12 Mar 2006 02:33 "bradb" <brad.beveridge(a)gmail.com> writes: > > Which were they? I made my own personal suite of CL utilities into a > > subdirectory of Cells just to avoid this. > > > > Actually, you're right there is a link to CVS from here > http://common-lisp.net/project/cells/. I use CVS all the time, but > what I don't usually do is pull from repos. Most Sourceforge pages > have the exact command that you need in order to get the latest CVS, in > your case this is (I think) cvs -z3 -d > :pserver:anonymous:anonymous(a)common-lisp.net:/project/cells/cvsroot co > cell-cultures/cells. It would be nice to have that somewhere on the > main page to ease CVS access. Oops, I hear some maintenance work calling. Use this command instead: cvs -z3 -d :pserver:anonymous:anonymous(a)common-lisp.net:/project/cells/cvsroot co cells The cells-cultures stuff isn't how things are organized anymore. -- /|_ .-----------------------. ,' .\ / | Free Mumia Abu-Jamal! | ,--' _,' | Abolish the racist | / / | death penalty! | ( -. | `-----------------------' | ) | (`-. '--.) `. )----'
From: Tayssir John Gabbour on 12 Mar 2006 03:50 Ken Tilton wrote: > Tayssir John Gabbour wrote: > > * So, cells only update other cells in their own object instance (not > > even cells allocated as :class)? > > No. And, not to quibble, I would say cells can depend on cells of any > instance (so, yes, propagation (updating, as you say) can flow between > cells of different instances). Ok, now it make a lot more sense. It seems that the way you determine whether cell-1 depends on cell-2 is IFF cell-1 looked at cell-2 the last time cell-1's c? code ran. Shneaky shneaky. (If true.) Thanks, Tayssir
From: Ken Tilton on 12 Mar 2006 04:14
Tayssir John Gabbour wrote: > Ken Tilton wrote: > >>Tayssir John Gabbour wrote: >> >>>* So, cells only update other cells in their own object instance (not >>>even cells allocated as :class)? >> >>No. And, not to quibble, I would say cells can depend on cells of any >>instance (so, yes, propagation (updating, as you say) can flow between >>cells of different instances). > > > Ok, now it make a lot more sense. It seems that the way you determine > whether cell-1 depends on cell-2 is IFF cell-1 looked at cell-2 the > last time cell-1's c? code ran. Yes. So dependencies will vary after every invocation of, say: (c? (if (^a)(^b)(^c))) between A and B or A and C. Interestingly, this means inelegant code can create problems: (c? (let ((b (^b))(c (^c))) (if (^a) b c))) ....always produces dependencies A, B, and C, which is a lie. Note, btw, that dependencies are dynamic, not lexical: call a function that accesses a cell and you still get a dependency. > > Shneaky shneaky. (If true.) Sweet, right? It was not always that way, but then I finally grokked special variables and that changed everything. kt |