Re: how expressive are they?

[Sundar Narasimhan <address@hidden>]

   I didn't think the part I left out trivial; I would have written it if
   I thought it trivial.  (And I think five to eight hours --- the time
   implied by your 70-80% figure --- a rather conservative estimate of
   the time it would take to produce a really useful and convenient
   database mapping layer.) I don't see how syntactic abstraction helps
   any more with those things than with the bits I did implement.  You
   don't need macros to log updates and inserts to a transaction log;
   therefore, you don't need macros to do arbitrary things on updates or
   inserts.

See Kragen: I think we have a disconnect right here. 

First of, I couldn't care less about Python, or Haskell, or
<insert-your-favorite-language> here.

A lot of people think that dealing with persistence is just logging
updates and inserts in a transaction log. (I used to think databases
were just smart data structures too when I went into industry :). The
real reason I think of this as a good example is because it often
illustrates the mapping/concepts/issues that such macro layers have to
deal w/ in terms of reducing the code one has to write -- and mapping
from whatever programming language you are dealing with on the one
hand (often OO) and SQL/relational concepts on the
other. Intrinsically, if you don't deal w/ rollback/errors, or
multi-user issues, your code isn't dealing with the kinds of issues we
often care about. Intrinsically, if the syntax you invent to deal w/
these sorts of mappings is NOT different from the base language or
primitives thereof (reflection, or not, I don't really care), then
you've missed the point. Some of the papers that talk about macros
that Anton and others have posted make this point more accurately than
I can here. 

   You don't need macros to create classes on the fly (although
   I didn't; all the instances belong to the same Python class) from a
   list of strings naming the fields; therefore, you don't need macros to
   create classes on the fly from a database schema you get from your
   database server.

This is another place where the disconnect shows and this argument is
getting pointless. They key is what you said earlier - that you can do
this sort of thing to various sorts of degrees in "some" sub-set of
languages.

   I just implemented the parts to which macros seemed relevant, like the
   ability to miraculously turn ordinary assignment statements into
   arbitrary code execution.  I assert that you can do the rest without
   macros and without per-class code duplication too --- for an example
   of most of the facilities you want, I guess you could look at Zope ---
   but it surprises me that the example I posted doesn't provide
   sufficient evidence of this to you.

I know zope, and know it is powerful. It doesn't change my opinions
about macros one bit -- I say that because I've written lots of
repetitive DTML/python too :) And Zope's transaction model only works
in certain limited cases (and yes I know about clustering and what
Zope offers in terms of load-balancing).

   I don't know that I necessarily like reflection better than macros ---
   both take a lot of effort to maintain and debug, and I'd like to see a
   macro-based implementation of facilities similar to those provided by
   the Python example I posted --- but I assert that you can do all the
   things you have described your object managers doing in Python with
   reflection: getattr, setattr, __dict__, dir, __getattr__, and
   __setattr__.  I offer the program in my previous post as evidence, if
   not proof.

I don't care a bit about Python, really. The reason that APL or Matlab has
certain kinds of array operators means that you can write certain kinds
of programs shorter in those languages in others. We are talking about
a "general language feature" not one language vs. another. People like
me keep saying "we find macros useful" and you and others keep warping
our argument to "we find macros more powerful" and spend a great deal
of time trying to put "your understanding of what macros do" into some
example or other. I now understand Dan's wisdom of saying "macros are
heavy duty tools for heavy duty jobs" and leaving it at that.

I do wish you'd try to do what your example does in C or Java or C#
(macros may be less relevant to languages such as Perl, Python,
Smalltalk and dialects of Lisp -- even though no doubt, such options
have been considered several times over the objections of idealogues).