On 5/10/07, Adrian Howard <[EMAIL PROTECTED]> wrote:
On 9 May 2007, at 21:37, David Nicol wrote:
> [proposed macro syntax example:]
> macro hashkeyaccessor(fieldname) { sub fieldname { $_[0]->
> {fieldname}} };
> hashkeyaccessor $_ for qw/FIELD NAMES GO HERE .../;
>
> [summary of benefits of approach] What am I missing?
You're missing that you can execute code at compile time that
determines what code you generate.
I disagree, I think I included that, and you didn't see that I had.
so to be fully lispy the extension would need to support
defmacro keylookup(key) { $_[0]->{key}}
defmacro hashkeyaccessor(fieldname) { sub fieldname {
(keylookup fieldname) } };
(hashkeyaccessor $_) for qw/FIELD NAMES GO HERE .../;
as well as
www.gigamonkeys.com/book/macros-defining-your-own.html
Some devils brew of source filters and eval is the closest you'll get
in Perl 5.... Perl 6 with its explicit lexer/parser should give you
the full power of Lisp style macros.
the debate response to that is, "show me something besides
syntax succinctness you can do with a LISP macro that you cannot
do with such a code-generated string eval"
Adrian (recovering Smug Lisp Weenie :-)
That's fun link, the story of Mac the programmer, who eventually retires. The
article contains this:
* When you write macros, you're writing programs that will be
* used by the compiler to generate the code that will then be
* compiled. Only after all the macros have been fully expanded
* and the resulting code compiled can the program actually be run.
* The time when macros run is called macro expansion time; this
* is distinct from runtime, when regular code, including the code
* generated by macros, runs.
this separation of times sounds exactly the same as putting
an eval of generated source in a BEGIN block. Adding a source
filter to the brew has to potential to allow for succinctness and
clarity that is absent from the generated source situation due
to the trickiness of escaping sygills appropriately (easy to get
wrong, but you only have to get it once right, then it stays
working)
Later in the chapter, gigamonkeys admits that LISP macros also
suffer from the fact the human brain was not originially designed for
programming computers:
* In other words, you'll write a macro-writing macro: a
* macro that generates code that generates code. While
* complex macro-writing macros can be a bit confusing
* until you get used to keeping the various levels of code
* clear in your mind
LISP feature: macros that produce macros.
Perl equivalent: evalling generated source to produce functions to
eval generated source.
Can do it, yes. And it is a slightly bigger PITA than using LISP syntax.
If I find the time to put what I learned about source filters while
exploring writing a tail recursion optimizer (final result: there
are too many edge cases: if you really want tail recursion
optimization, learn about C<goto &subname> and use it) into
making my own macro syntax filter which will work as
exampled above, it will work as follows:
(1) remove pods and comments and abstract out quoting constructs;
(2) identify defmacro constructions, whatever they look like, convert
them to coderefs that take parameters and return the body as
evallable strings;
(3) identify expressions including defined macros, and run those
expressions immediately
(4) expand macros, even embedded in expressions, in results from (3)
(5) allow for macros declared in macro expansions to join the list
of declared macros from that point on
(6) allow for lexical scoping of macros
(7) allow for predeclaration of macros (? is this useful)
(8,...) extend macro language
What's already on CPAN:
http://search.cpan.org/~segv/Macro-0.2/Macro.pod
Essentially what I'm describing, but with a clunky Parse::RecDescent
syntax that may be more complex than doing it yourself; and with
a bugs/todo list at the bottom that restates various points made
above -- I will start with Macro-02 instead of from scratch if I do this
http://search.cpan.org/~autrijus/Filter-Macro-0.11/lib/Filter/Macro.pm
misleadingly named, Filter::Macro appears to be Pollute::Persistent
plus hints accomplished through source filtering.
TERN (The Extensible Rewriting Notation) mailing list,
http://lists.nongnu.org/mailman/listinfo/TERN-discuss
The "Take away David Nicol's internet access committee"
mailing list, (...)
--
practical solutions to systemic problems
