Re^2: The Case for Macros in Perl

[eyepopslikeamosquito]

Yes, I think the OP should be more specific about what type of macro he is asking for:

• Textual macros (e.g. C pre-processor).
• Procedural macros (e.g. PL/I, assembler).
• Lisp macros.
• Perl 6 macros aka syntactic/hygienic macros.

Update: more P6 macros blog posts from Carl Masak:

• Perl 6 macros progress report after a long break
• Macros: thunkish parameters
• Macros: feedback on thunkish parameters
• Macros: nesting macros
• Macros: allowing two terms in a row

[raiph]

»»» This post is about the immature Perl 6, not the rock solid Perl 5 «««

eyepopslikeamosquito's list above might lead some to think that the P6 spec, and Rakudo implementation, don't (aspire to) support Textual and Procedural macros and that their macros don't (aspire to) cover the ground that Lisp macros cover. So, for the record, although this is mostly OT:

• The P6 macro design (per spec) supports, and Carl Mäsak (Rakudo dev) plans to implement, Textual (unhygienic) macros (included in both eyepopslikeamosquito's list of macro types and the ones listed in wikipedia's page on macros).

• P6 macros are written in P6. Aiui that means they (also) provide the Procedural macro type listed by eyepopslikeamosquito and WP.

• P6 macros are (eventually) supposed to deliver most of the practical benefits of Lisp macros in an easier-to-apply or at least more Perlish form despite the fact P6 isn't homoiconic.

• The P6 macro features described in the 2012 advent article on macros (the one eyepopslikeamosquito linked above) still work. I know Carl will appreciate seeing folk trying macros out on #perl6 so he can see what folk want to do with them and/or reporting bugs to RT.

• Aiui, relative to his original proposal/plan, Carl's progress report from Nov 2012 still applies. Update: Macros progress report: after a long break.

• Since then Carl has continued to test and discuss user-facing and internal design ideas and issues related to macros, some of it on #perl6. (Feel free to join the conversation.)

• It's likely that P6 macros are going to take a different or additional form as recently suggested by some recent comments by Larry Wall such as "a macro that is written like token infix:sym<op> but 'make' returns the new AST" and Carl's latest blog post.

[einhverfr]

Perhaps with an agreed-upon Perl 6 spec we can eventually get the same backported into Perl 5 ;-)

[raiph]

»»» This post is about the immature Perl 6, not the rock solid Perl 5 «««

I'm not aware of a compelling reason to wait for 6.0.0. cf Moose which used P6 OO design as-it-was-then as its starting point.

I think a one hour review/consideration of P6 macros as they are now would probably be worthwhile for anyone considering the design of a macro facility for P5 today, even if their conclusion is "we can't use any of this in P5". The heart of the Macros spec is in the Macros section of the Subroutines spec, so it's fairly easy to review the overall design. And the basics, plus hygiene, have already been implemented in Rakudo, so it's easy to try it out too, eg by using the online evalbots on #perl6. I'd be happy to provide further pointers if you or anyone else expresses interest.

Another possibility I'm particularly curious about is ways in which P5 and P6 can leverage each other to create a greater Perl. While I don't currently see a way to do this in relation to macros, perhaps someone more creative than I could use Inline::Perl5 and/or v5 to bring some macro magic to P5.

[einhverfr]

Actually thinking of something like a Lisp macro, in particular being self-processed source-code not merely on the textual level but on a level higher than that (below the perl 6 macro level though)

In this specific case, my thinking is to create a text string and eval it and see if that is cleaner. But it would be nicer to be able to process statements of perl as statements of perl, not as strings which will hopefully compile.