Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^3: Macros, LFSPs and LFMs

by Aristotle (Chancellor)
on Jun 13, 2003 at 11:34 UTC ( #265646=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^3: Macros, LFSPs and LFMs
Re: Re^3: Macros, LFSPs and LFMs
by BrowserUk (Pope) on Jun 13, 2003 at 12:11 UTC

    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.

        I can see your point here. Ive done things like this

        sub assert{ my ($stmt,@args)=@_; my $ok=eval"$stmt" or die "Failed to eval assertion '$stmt':$@"; unless ($ok) { no warnings; my $str=eval qq("$stmt") or die "Failed to eval assertion '$stmt' as a string:$@"; die "Failed assertion '$str'\n"; } }

        which works reasonably well, but obviously isn't as satisfactory as your approach, and could even be a security risk as presently written if it were run on untrustworthy data.

        Anyway, Itll be nice though when the new stuff is out at a production grade. I look forward to it. :-)


        ---
        demerphq

        <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
Re: Re^3: Macros, LFSPs and LFMs
by demerphq (Chancellor) on Jun 15, 2003 at 07:54 UTC

    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://265646]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2014-08-20 13:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (113 votes), past polls