greg wrote: > Ken Tilton wrote: > >> So this: >> (defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv)) >> ,@reverser) >> >> becomes this: >> >> (defmethod tf-reverse ((id (eql ',sub-id)) tf drv >> &aux (opnds (drv-opnds tf drv))) >> (loop for resx in (results drv) >> ,@reverser)) > > > I don't see why you can't just write a function that > loops over the results and calls the user's reversal > function for each one.
That was the original coding, but notice that a derivation (DRV) is an argument to tf-reverse. Can you say "encapsulation"? :) What if that changes? It did. I used to have just one result per derivation, until a multi-result case came along. Since I will be having many dozens of these I might well try to keep as much code as possible out of them (encapsulation de damned <g>) to minimize the inevitable hit when I refactor, but I have macros so I do not have to. > > def reverse_multiple(skill, resx_list, opnds): > for resx in rex_list: > skill.reverse(resx, opnds) > > There's no need to macro-expand this code into every > reversal function, when it can be done once as part of > the framework that calls the reversal functions. Rather than go into "argue mode" before fully understanding the issues, please note that I am just looking to learn (without judgment) what the Python equivalent would be. Things I offer are not "you can't touch this!", they are "what does the Python look like?". Afterwards we can get into a pissing match. :) ken -- Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm "Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it." -- Elwood P. Dowd "I'll say I'm losing my grip, and it feels terrific." -- Smiling husband to scowling wife, New Yorker cartoon -- http://mail.python.org/mailman/listinfo/python-list
