Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Re: Macros, LFSPs and LFMs

by adrianh (Chancellor)
on Jun 11, 2003 at 22:20 UTC ( #265209=note: print w/replies, xml ) Need Help??

in reply to Re: Macros, LFSPs and LFMs
in thread Macros, LFSPs and LFMs

On the other hand, I'd also like to see a few examples of what people would use a macro facility for in Perl. Assuming that p5 had a C-like

#define name(arg[,arg]) {\ some code here\ }

I wouldn't use it for C-like purposes. C-like macros are not that powerful - you can only do basic textual substitutions. To quote Synopsis 6:

Macros (keyword: macro) are routines whose calls execute as soon as they are parsed (i.e. at compile-time). Macros may return another source code string or a parse-tree.

Returning a parse-tree is where it gets interesting. What we get here are LISPish macros. We'll be able to write code that's run at compile time to create our own syntax.

Want a switch statement in Perl6? Just write one.

Want to add AOP or Design by Contract support to Perl6? Just write some new syntax.

Want to create a domain-specific language so you can write code that more directly reflects the problem domain? Yes - you guessed it - just write some new syntax!

There's a discussion of macros on perl.perl6.language that you might find interesting. Also read the relevant bit of Apocalypse 6.

Macros - can't wait ;-)

Update: Just come across A Macro System for Perl?, which has some relevant material for those who are interested.

Replies are listed 'Best First'.
Re: Re: Re: Macros, LFSPs and LFMs
by BrowserUk (Pope) on Jun 11, 2003 at 23:33 UTC

    Thanks muchly for that. Never having done anything with Lispish languages, much less it's macro facilities, I've never really encountered macros in this form.

    The perl.perl6.language thread was particularly useful. I'd read that bit on macros in Apo.6, but hidden amongst so much else, I think I must have closed my eyes and held my breath as it washed over me. Time to go back and read itagain. I think that LW summed up the pro's and cons of macros in this form with two statements--that probably shouldn't be taken out of context, but will serve me as anchors in my grep for further info and an opinion.

    This is the most dangerous kind of return value, and the least likely to produce coherent error messages with decent line numbers for the end user. But it's also very powerful. Hee, hee.

    A lot of Perl is fun, and macros are fun, but in general, you should never use a macro just for the fun of it. It's far too easy to poke someone's eye out with a macro.

    And as far as Macros - can't wait ;-) goes--I probably agree, but I'll reserve judgement until I form an opinion. This is one of those things that I find very difficult to grasp the significance of at a purely theoretical level, a couple of practical uses will probably convince me.

    I tend to be pretty impirical by nature. That's probably why I have such a hard time with pure math once you get beyond stuff you can at least model with a few empty loo-roll holders and some sticky-back plastic. I have vague memories of something about a blind French mathematican that proved that you can turn a sphere inside out (topologicaly speaking) without breaking the surface. I concluded that you would have to be blind to even concieve of such a notion:)

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

      Well, you know all these attempts to add syntax to Perl5 using sub(&;)-ish prototypes? (Like try { ... } catch { ... }; which look like keywords but are really function calls.) That device is very limited and carries risks of leaking accidentally created closures which makes it dangerous to use in any persistent environment. In Perl6, even if the language didn't already have these, it would be easy to write macros that transform this into code behaving exactly as if they were real keywords.

      Or consider the Acme::Don't module and esp Simon Cozen's take at it; this would be trivial to implement with a Perl6 macro.

      Then we have cases like the Test modules. It would be nice if there was a way for ok() to actually "understandd" the code of the test being evaluated, so we could just write ok($foo eq $bar, 'calculation [...]') - currently, in order to get the actual test described in the failure message you must use a specialized derivative function such as is($foo, $bar, 'calculation results should equal safety check'). Instead of having to learn all the testing modules and the tests they provide (and hunt around for the module that implements the kind of test you want or eventually rolling your own), you just let a macro figure out how to DWIM with Perl code, whose syntax you presumably already know well.

      Or PDL. It basically adds a whole new sublanguage to Perl for mass numbercrunching. In many cases it has to try to fit a square peg into a round hole in order to somehow map a mathematically oriented notation into Perl syntax in a semi intuitive fashion. With true macros, it could actually add new definitions of mathematically oriented syntax to the language.

      And these are only the most obvious examples because they already attempt to recast Perl5 syntax for a specific subject. Probably any very deep but narrowly defined programming field can likely benefit from casting its most basic premises into actual, additional supporting syntax for the language.

      Makeshifts last the longest.

      Another application that just popped into my mind - albeit not one that necessarily needs the full power of LISPish macros: real assert()s. And while they don't need it, they too can exploit the full power of macros, by being able to grok the assertion code similar to the way I outlined for the ok() function in tests.

      Makeshifts last the longest.

        I'm still having trouble with this.

        I still can't see what compile-time executed macros get me that C-style text-substitution macros don't?

        Maybe I can see it being used to define new operators, (e.g %% to do my( $div, $rem) =  10 %% 3; print $div, $rem; # 3 1, even this could be acheived with a C-style macro, if perl required whitepace between tokens.

        Even inlining functions can be easily achieved using C-style macros, though it is much better taken care of using a keyword/attribute/trait. Either marking the sub to be always inlined, or marking the use of the function to be inlined. This clearly leaves the function name intact and readily understandable to the reader.

        Using a macro would to inline the sub would mean using another identifier as a substitute for the actual sub name, which is okay if people stick to some convention.

        sub assert { my($x, $y, $z) = @_; if( $x ne $y ) { eval $z; } } macro ASSERT( x,y x) => { if( (x) ne (y) ) { eval (z); } }

        Much better to use sub assert : inline {...}

        Or  assert( 'this', 'that', "croak('assert failed')" ) : inline;

        Now, the obvious (clever?) answer to my dilemma is that if P5 had 'proper' macros, I could implement either or both forms of inlining syntax shown above, and wouldn't have to petition p5p to make my case for this.

        So my question becomes, assuming that a 'proper' macro facility existed or could be added to P5, what might the macro(s) to achieve the above inlining syntaxes look like?

        Anyone care to speculate? Doesn't have to be fully thought through, comply with LW's high standards, etc. Just a possible syntax for adding the facility to designate and implement the inlining of functions using my syntax above.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

        Real assertions (compile time) are coming, and they'll be pretty powerful, essentially allowing you to prune the parse tree using command line switches and use statements.


        <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (5)
As of 2021-04-21 19:52 GMT
Find Nodes?
    Voting Booth?

    No recent polls found