Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Macros v. Source Filter was: Lisp to Perl compilation

by Elian (Parson)
on Jan 16, 2004 at 16:58 UTC ( [id://321830]=note: print w/replies, xml ) Need Help??


in reply to Macros v. Source Filter was: Lisp to Perl compilation
in thread Lisp to Perl compilation

Lisp macros act on the parsed version of your code--they go after the parser. Source filters, on the other hand, work on the raw text of your code--they go before the parser.

For a language like Lisp, there's argably little difference (Lisp is dead-simple to parse) though it's definitely less of a hassle to work on the parsed tree. For a language like perl, macros would be a very nice thing since parsing perl correctly is a profoundly non-trivial exercise.

Macros and source filters both have their place. It's just a different place...

Replies are listed 'Best First'.
Re: Macros v. Source Filter was: Lisp to Perl compilation
by Abigail-II (Bishop) on Jan 16, 2004 at 17:09 UTC
    In Perl, one can modify the program after the parser as well, with the help of the B::* class of modules, and from within a CHECK block.

    Abigail

      As Elian says lisp macros act on the parsed representation of the code. Lisp code is trivial to parse. It is also made up of simple, fundamental lisp data structures. The power of lisp comes from its ability to trivially represent lisp programs as lisp data. This allows you to write programs which write programs, which is very powerful.

      Suppose your language lacked a for loop (as in C and perl) but had a while loop. In lisp it would be very easy to implement one as a macro. This macro for loop would be just as efficient as if the language provided one in the first place. This is a fairly trivial example but it might give you an idea. In most languages you just can't do that. Essentially this gives you a 'programmable programming language' (to quote Paul Graham). It lets you extend lisp into a domain specific programming language for whatever domain you want with no loss of speed. A lisp programmer would not tend to use XSLT for transforming XML - they would just extend lisp to implement the same functionality.

      Extending perl in this way with source filters (adding bits to the language) would not be easy due to the difficulty in parsing perl. It is possible that the B:: modules could be used to do a similar thing in perl. I'm not sure though. It wouldn't be easy due to the complexity of the parsed perl programs. Interesting thought though.

      Well, if by "one" you mean you, or me, or a very small handful of other people, sure. We can do the same with XS, too--it's still far less safe than Lisp macros, and a bare step above pack "p" and slamming bits directly into memory. It is, however, acting on the final internal representation of the program, rather than on the parsed version of the program. (Though in perl's case there is no actual difference, as there's no 'just parsed' version to manipulate before it gets turned into the structures that get executed)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://321830]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2024-03-19 04:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found