Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: Re: Macros, LFSPs and LFMs

by BrowserUk (Pope)
on Jun 11, 2003 at 23:33 UTC ( #265225=note: print w/ replies, xml ) Need Help??


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

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



Comment on Re: Re: Re: Macros, LFSPs and LFMs
Re^3: Macros, LFSPs and LFMs
by Aristotle (Chancellor) on Jun 12, 2003 at 01:20 UTC

    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.

Re^3: Macros, LFSPs and LFMs
by Aristotle (Chancellor) on Jun 13, 2003 at 11:34 UTC
    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


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

        Well, I suppose one thing would that you would get proper prototype/argument handling.

        -Lee

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

        The advantage lies in the fact that the passed code is preparsed for you. Remember the traps with things like x*x vs (x)*(x) in the body of a C macro? None of that silliness here.

        While that is just nice, the power becomes impressive when you consider that since you can easily examine what the parameter code does without error prone manual parsing. A failed assert($foo == $bar && $baz == $quux); can automatically return an error along the lines of "$foo == $bar succeeded, but $baz == $quux failed". Given limited complexity, the macro could also automatically generate errors like "$foo (value: 21) was expected to be in the range from $bar (value: 8), inclusive, to $baz (value: 16), exclusive" when you assert($bar <= $foo < $baz);. Since the intent of a piece of code is implicit in itself, writing comments violates the principle of once and only once, so a reduction of human written commentary to be manually kept in sync with the code manually is very desirable.

        The same principles apply for an ok() macro used in unit testing.

        Makeshifts last the longest.

      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.


      ---
      demerphq

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (14)
As of 2014-09-18 13:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (115 votes), past polls