RE: macros vs. blocks

[Trevor Blackwell <address@hidden>]

> So, you wrote some code (in Perl?) to generate Perl functions, using a DTD
> as input?

> If so, that code you wrote is the kind of code for which macros provide a
> generalized abstraction.  I'm not sure why you say that macros wouldn't
have
> helped you; that's exactly the kind of thing they're intended for.
(Unless
> I've misunderstood what you're referring to.)

I didn't see it this way at all -- I saw it as defining a bunch of
names which all called the "wrap in tag" function with slightly different
parameters. Closures provide the natural way to do this, where you link
function names to the same closure with different environments.

The toy version of the code would look like (sorry, this involves some
obscure parts of Perl syntax...):

for my $fn in (qw(table trow td ...)) {  # for each HTML operator
    &{$HTML::{$fn}} = sub {         # define a function in the HTML package
named $fn
        my($content)=@_;
        print "<$fn>";              # The binding of $fn makes each closure
different
        &{$content}();              # like (call content)
        print "</$fn>";
    };
}

You can do the same in just about any dynamic language like
Python or Lisp.

So it's all in how you look at the problem. If you see it as
defining a bunch of textually similar functions, you think
macros. If you see it as a general "wrap-in-tag" function
parameterized by what the function is, you think closures.

Perhaps this dichotomy of viewpoint is big enough to warrant
language features to appease both kinds of thinkers.

--TLB