in reply to Specific Examples? - Re: A Macro System for Perl?
in thread A Macro System for Perl?

Well, that's rather the question, isn't it? I guess at the very least I'd like to be able to write something that looks and feels like suroutine but is inlined into the code that "calls" it, thus avoiding the overhead of a real subroutine call: 
macro beep ($) {
   print LOG "BEEP: $_[0]\n";
}

[download]
Then I can beep() to my heart's content without killing my program with the subroutine overhead.

But that's just the start. Reading "On Lisp" made me realize that an expressive macro system can do more than just provide a fast, clean alternative to subroutine calls. How would this work in Perl, which is a lot more varied than Lisp? I'm not at all sure.

-sam

Replies are listed 'Best First'.
Re: Re: Specific Examples? - Re: A Macro System for Perl?
by mdillon (Priest) on May 03, 2002 at 19:56 UTC
    I think you will be able to do this in Perl 6: sub beep ($text) is inline { print $LOG "BEEP: $text\n"; } I've seen examples of this (is inline) for custom operators on the perl6-language list.
[reply]
[d/l]
      Sounds good. So how do we get it in Perl 5? I live in the present and Perl 6 just seems like a nice daydream most days.

      -sam

[reply]
Re: Re: Specific Examples? - Re: A Macro System for Perl?
by shotgunefx (Parson) on May 03, 2002 at 20:28 UTC
    Keep in mind though Lisp is somewhat slow to begin with. I'd wager that mundane Perl coding would still beat profiled Lisp.

    -Lee

    "To be civilized is to deny one's nature."
[reply]
      I wouldn't bet that. A good compiled lisp, and there are a number of them, will beat the pants off of perl for many things. (Regular expressions being a notable exception)
[reply]
        To be honest, my experience with Lisp is limited. The view I had of Lisp being slow was due to
        1. Working with a platform that was implemented in Lisp by pg that was slow and memory intensive compared to other languages.
        2. A discussion between Paul Graham and Trevor Blackwell where they benchmarked some simple and common operations using C, Perl and Lisp.

        (I'm trying to dig it up now.) If I remember correctly, ANSI Clisp had to perform around 400+ operations to print a single character. Don't quote me on that though. I'll try and find the doc.

        -Lee

        "To be civilized is to deny one's nature."
[reply]

      Hello. One of the Monastery's resident Common Lisp users here. I'd take that wager in a second. With the exception of certain things that Perl is explicitly optimized for (like regexes, string processing and such) I'd expect a quality Lisp (e.g. Lispworks, Allegro, CMUCL) to do much better. For example, I have considerable code doing numerical computations in Lisp, and it's typically not even worth rewriting it in (for example) C to attempt to get a speed improvement.

[reply]
      Now why would you just assume that? There are some really fantastic optimizing compilers for Lisp out there, not to mention veteran Lisp hackers with 20-odd years of experience making fast Lisp code...

      That's like saying that mundane C will beat profiled Perl, which is just as false.

      -sam

[reply]
        As I had noted in my post to Elian, I got the impression (mistaken or not) working with a platform that was written in Lisp written by Paul Graham and on some notes I've seen back and forth between him and Trevor Blackwell. I figured since Paul has for all intensive purposes wrote the book on Lisp, it is pretty optimized.

        Now the benches that I saw were mainly IO based and it was a lot slower than Perl which was slower than C which was slower then ASM.

        I could certainly be wrong but Lisp seems to bring with it a lot of inherent weight. Again, this is in my very limited experience with it. I don't doubt that Lisp is better suited for certain tasks. In fact my coding style has taken on a more Lisp-ish style in the past 6 months. (Though I would take Perl over Lisp anyday.)

        -Lee

        "To be civilized is to deny one's nature."
[reply]

In Section Meditations