For Kenny Tilton: Why do I need macros revisited.
Kenny Tilton
ktilton at nyc.rr.com
Sat Aug 23 15:13:58 EDT 2003
Michele Simionato wrote:
> Kenny Tilton <ktilton at nyc.rr.com> wrote in message news:<3F45A7BF.4060806 at nyc.rr.com>...
>
>>You are absolutely right. Metaclasses are killer. I am surprised
>>Pythonistas afraid of macros let them into the language!
>
>
> Me too. Actually they are quite *scaring*.
A few months back I started on a PyCells project, and of course was
having great fun down at the metaclass level. It was a little daunting
compared to the Lisp MOP, which just takes the same concepts of calls
and instance and does a conceptual-shift-up (new machine language
instruction?) so a class is now an instance (of a metaclass, which is
just another class really--the "meta" is only to keep one's head
straight). Python might be viewed as easier because it jumps over to
using internals such as that __dict__ thing (sorry if that is wrong, it
has been a while and I only played for a few weeks), so it there is none
of that class-being-an-instance confusion. Fun stuff, either way.
>>I actually had
>>a metaclass implementation of Cells until I decided to release the
>>source. The MOP is not part of the standard, and it shows across
>>implementations. Hell, MCL does not even expose a MOP.
>>
>
>
> Quite impressive. You are actually saying that you do prefer Python
> over
> Lisp on a problem of ultra-high level programming which should be
> the rightful Lisp playhouse ... To be fair, the reason is not lack of
> power by Lisp, but lack of standardization, still it is something that
> makes me thinking ...
I'd call it a draw. The CLOS MOP is a better playground, but Python has
a clear win in that there is only one Python. If I really need the MOP
for a project, I just pick a CL which exposes it. If I want to deliver a
package any lispnik can use, I better not use the MOP.
btw, I forgot the other reason for switching back to a macro-based
implementation: performance. It turns out ACL and I think other
implementations optimize method dispatch by (wait for it) memoizing
which method to invoke for which combo of arguments. A half-baked test
showed maybe a 30% slowdown of SLOT-VALUE because I had specialized
SLOT-VALUE-USING-CLASS, the GF that lies just under S-V.
You know, when I converted to the MOP for Cells I was all excited at how
great it would be to do it in a metaclass and make Cells almost
invisible. At the time I decided to switch back so I could share Cells,
I noticed that that arrow could point the other way: macros are so cool
that Cell semantics can be achieved /without/ tinkering with the object
model! You tell me, which is cooler? I honestly don't know. Certainly in
CL where the MOP did not make it into the standard (and the possible
loss of CLOS optimizations) put the burden on a metaclass approach to
prove a macro solution is not possible.
Cell internals without the metaclass is actually simpler, because now
slot-value is a backdoor. I had to set a flag under the metaclass
version so cell internals could actually get at a slot's value! On the
other hand, not having the backdoor may have been vital to marrying my
Cells metaclass to a persistent object metaclass. (How do you like that?
Multiple inheritance of metaclasses! <g>) Haven't tried ripping out the
metaclass of Cells from that project yet, so I do not know if I can.
Even if CLOS metaclasses were standard, kind of in the spirit of some of
this thread, I think I would like to avoid doing Cells by tinkering with
the object model. A hack that kinda disappears at run time (the macros
expand into vanilla CL) is probably going to play better with other
hacks, including not breaking optimizations. ANd it may be a Message
From God(tm) that Cells internals got simpler when I ripped out the
metaclass thing.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
More information about the Python-list
mailing list