Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > For Kenny Tilton: Why do I need macros revisited.

Reply
Thread Tools

For Kenny Tilton: Why do I need macros revisited.

 
 
Michele Simionato
Guest
Posts: n/a
 
      08-23-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) (David Mertz) wrote in message news:<(E-Mail Removed)>...
> "Andrew Dalke" <(E-Mail Removed)> wrote previously:
> |I've seen David Mertz' xml_pickle code which makes good use of
> |[metaclasses], but don't yet follow how it works.
>
> I'm afraid I must insist here that the use of metaclasses in
> gnosis.xml.pickle is utterly trivial, and just for show. You'll
> have to look elsewhere for "good use" of them .
>
> Yours, David...


For instance Psyco was using metaclasses to wrap the methods to
"speed-up", at least when I looked at version 0.4.
This was a quite clean usage, simple and effective.
When you need to wrap many methods in a class (for instance for
logging purposes or other reasons) a metaclass is most probably
the best solution you have at your disposal.

Michele Simionato, Ph. D.
(E-Mail Removed)
http://www.phyast.pitt.edu/~micheles
--- Currently looking for a job ---
 
Reply With Quote
 
 
 
 
Paul Foley
Guest
Posts: n/a
 
      08-23-2003
On Fri, 22 Aug 2003 11:10:49 -0400, Terry Reedy wrote:

>> Scheme macros are not the same as Lisp macros. Scheme macros are a
>> lot more complicated (and less useful; but most Scheme implementations
>> also offer Lisp-style macros...)


> Please excuse my confusing of Scheme with Lisp. I am pleased to find
> that my difficulty in reading the Scheme macro stuff wasn't just me.
> But note that there have been proposals that if Python were to have a
> macro facility, it should be 'hygenic', which I presume means like
> Scheme macros.


> Until some advocate of a Python macro facility adds more detail to the
> proposal beyound 'Lisp/Scheme-like maco facility', it is really hard
> for someone like me, who has used neither, to have much of any
> concrete idea of what is being proposed.


I don't know what others are proposing.

In Lisp, a macro is really just a function like any other (so people
arguing against macros who are not also against functions are clearly
insane!). It takes two arguments: a "form" (i.e., some Lisp code) and
an "environment" (a fairly useless opaque object), and returns more
Lisp code. So (a simplified version of) EVAL in a Lisp without macros
might look something like

(defun eval (form)
(typecase form
(symbol (symbol-value form))
(atom form)
(cons (apply (first form) (mapcar #'eval (rest form))))))

and to add macros, all that's necessary is

(defun macroexpand (form)
(if <form is a macro form>
(macroexpand (funcall (macro-function (first form)) form <environ>))
form))

(defun eval (form)
(let ((form (macroexpand form)))
(typecase form
(symbol (symbol-value form))
(atom form)
(cons (apply (first form) (mapcar #'eval (rest form)))))))


If you write a macro, LIST2, such that (LIST2 1 2 3 ...) expands into
(LIST (LIST 1) (LIST 2) (LIST 3) ...), and then you use it in a
function like

(defun foo (list)
(let ((x (list2 1 2 3)))
...))

in a Lisp-2 (i.e., a language with separate namespaces for variables
and functions, so you can have both a variable and a function with the
same name at the same time) there's no problem, but in a Lisp-1
(single shared namespace, like Scheme and Python) you'd have a big
problem: when the list2 macro is expanded, "list" is a variable -- the
argument to "foo" -- not the list-constructing function the
macro-writer expected.

So Scheme introduced the so-called "hygienic" macros [a bad name,
implying that non-hygienic macros are "dirty" and to be avoided;
"hygienic" macros are the ones I want to avoid!], where names used in
the macro expansion are in the scope where the macro was defined,
rather than the scope that's in effect where it's expanded, so that
"list" in the expansion refers to the list function, not the argument
to foo, and bindings made by the macro are not visible to code that
comes in from user code.

But Scheme macros are not just functions like Lisp macros, either. A
Scheme macro is defined as a set of patterns to be matched against
the code, and an associated rewrite rule which specifies the code to
use instead. [I don't see any reason why these rules need to be
written in a Lispy syntax...]

--
Just because we Lisp programmers are better than everyone else is no
excuse for us to be arrogant. -- Erann Gat

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
 
Reply With Quote
 
 
 
 
Kenny Tilton
Guest
Posts: n/a
 
      08-23-2003


Michele Simionato wrote:
> Kenny Tilton <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>
>>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

 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      08-24-2003
Kenny Tilton <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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 don't follow you. In Python it is just the same, a class is just an
instance of a metaclass, a metaclass is just an instance of a meta-meta
class, etc. Metaclasses are classes, their simply have a different
type.__new__ method than object.__new__ so the instantiation syntax
looks a bit different.

> 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.



Hear, hear, people who say CL is more standard than Python!
> (How do you like that?
> Multiple inheritance of metaclasses! <g>)


I need more multiple inheritance for metaclasses than for classes.
You maybe interested in this recipe of mine:

http://aspn.activestate.com/ASPN/Coo.../Recipe/204197

> 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.
>

As always, the most abstract solution is not necessarely the best
solution.

Michele Simionato, Ph. D.
(E-Mail Removed)
http://www.phyast.pitt.edu/~micheles
--- Currently looking for a job ---
 
Reply With Quote
 
Jacek Generowicz
Guest
Posts: n/a
 
      08-24-2003
(E-Mail Removed) (Michele Simionato) writes:

> > 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.

>
> Hear, hear, people who say CL is more standard than Python!


It is. The MOP did not make it into the standard, which is a pity, but
does not detract from the fact that the standard exists.

Actulally, the MOP is a particularly thorny issue, in this respect, as
it is _almost_ standard.
 
Reply With Quote
 
Kenny Tilton
Guest
Posts: n/a
 
      08-24-2003


Michele Simionato wrote:
> Kenny Tilton <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>
>>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 don't follow you. In Python it is just the same, a class is just an
> instance of a metaclass, a metaclass is just an instance of a meta-meta
> class, etc. Metaclasses are classes, their simply have a different
> type.__new__ method than object.__new__ so the instantiation syntax
> looks a bit different.


Glad I said it had been a while! Maybe I was less confused on the
Python MOP because I had already done a CL MOP hack?

>
>
>>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.

>
>
>
> Hear, hear, people who say CL is more standard than Python!


I doubt they say precisely that, if standard means "the same across all
implementations".

What I would say is that CL stands at the end of the long road Python is
now headed down, with divergent branches (not a problem for Python)
brought together in a big, stabilizing spec.

Python is more like a volcanic island rising out of the sea, still being
formed, features still being debated. Heady days, being there at the
creation. Then again, "may you live in an interesting time" is a Chinese
curse.



--

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

 
Reply With Quote
 
Donald 'Paddy' McCarthy
Guest
Posts: n/a
 
      08-25-2003
Jacek Generowicz wrote:
> "Terry Reedy" <(E-Mail Removed)> writes:
>
>
>>Until some advocate of a Python macro facility adds more detail to the
>>proposal beyound 'Lisp/Scheme-like maco facility', it is really hard
>>for someone like me, who has used neither, to have much of any
>>concrete idea of what is being proposed.

>
>
> Until some advocate of a Python macro facility adds more detail to the
> proposal ... it is really hard for me to have much of any concrete
> idea what is being proposed ... because Lisp-style macros rely on the
> fact that Lisp code is expressed in a fundamental Lisp data structure,
> in the form of its parse tree. This ain't the case in Python, so the
> whole macro business suddenly gets more complicated by an order of
> magnitude or two.
>
> I just can't imagine what such a macro system would look like. Maybe
> someone with deep knowledge of Dylan can enlighten us.

You might take a look at:
http://groups.google.com/groups?hl=e...hisBIT&rnum=12

This was my attempt at putting down some of the things that I'd like to
see in Python Macros/

Cheers, Pad.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Explanation of macros; Haskell macros mike420@ziplip.com Python 80 11-07-2003 02:22 AM
Re: Explanation of macros; Haskell macros Michael T. Babcock Python 0 11-03-2003 01:54 PM
Re: Explanation of macros; Haskell macros mike420@ziplip.com Python 5 11-01-2003 01:09 AM
Re: Explanation of macros; Haskell macros mike420@ziplip.com Python 1 10-07-2003 04:07 PM



Advertisments