in reply to The Case for Macros in Perl

If it were me, I would probably not prioritize macros as being particularly important.   I like to see, right there in front of me, the source-code that the interpreter is going to finally execute.   If I wanted to use macros to generate that source-code, I would probably do it as a separate step which generated a .pl file as its output, and I would not ask the language system to do that for me.   (I did very strange things along those lines using Template::Toolkit once, but I’ve sobered-up since then ...)

Replies are listed 'Best First'.
Re^2: The Case for Macros in Perl
by BrowserUk (Patriarch) on Sep 16, 2014 at 09:21 UTC
    I like to see, right there in front of me, the source-code that the interpreter is going to finally execute.

    That makes as much sense as a chocolate teapot, and survives the heat of reasoned thought for about as long.

    By that logic, you would never use subroutines -- much less those imported from a different file -- nor symbolic constants; nor enumerations; nor object methods.

    Hell. You couldn't possible use Perl; because it is actually executed as C; but then the C is actually assembler; and assembler is just a symbolic representation of the processor opcodes, so you would have to program in hex. But then hex is just a representation of the underlying binary, so you'll have to code in the binary to achieve your goal.

    Ah! Still then, the processor opcodes are actually translated into micro code before they can be executed...

    A macro -- done right -- is simply an abstraction just like subroutines or symbolic constants. A way of clarifying source code by allowing what the programmer reads to more closely reflect the purpose of the code -- the algorithm being implemented -- not the mechanics of that implementation.

    But then, logic never was your strong suit.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re^2: The Case for Macros in Perl
by einhverfr (Friar) on Sep 18, 2014 at 06:27 UTC

    That view makes a lot of sense for a lot of applications. Don't get me wrong. I think my college calculus professor was right when he said that in mathematics, power tools are ineligant when hand tools will suffice. That attitude won't lead you far wrong in software development either.

    The problem though is that power tools are sometimes better at some things than the hand tools are. In this case we can't generate through compiled Perl code alone an elegant function to provide the functionality so we are left with, as here, a baroque and generalized version, or we get to generate Perl as text strings, then compile it and install the resulting function in the symbol table.

    To some extent once you get into perl that generates functions and installs them in the symbol table, you are already outside hand tool territory. The question is what one can do to create elegant code at that point.

    Macros are helpful because they allow for better tailoring of the code generated. I don't think they should ever be a tool of first resort, but they can be really, really helpful in some areas.

[reply]

In Section Meditations