Macros?
Perl6 will have macros. Good. Cool. But, sadly, that seems to be close to the most specific thing anyone says about the subject. There is some further discussion in Apocalypse Exegesis 6, but nothing in the Synopsis. Now, considering that macros are a language feature and that the Synopses are presented as the language spec, I wonder if there shouldn't be something there. Exactly what, though, I won't pretend to know. :) -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: Macros?
On Sun, Jan 29, 2006 at 18:53:25 +, Herbert Snorrason wrote: Perl6 will have macros. Good. Cool. But, sadly, that seems to be close to the most specific thing anyone says about the subject. There is some further discussion in Apocalypse Exegesis 6, but nothing in the Synopsis. Now, considering that macros are a language feature and that the Synopses are presented as the language spec, I wonder if there shouldn't be something there. Exactly what, though, I won't pretend to know. :) Basically the plan is that when an internal AST language is decided upon, the macros will be able to get either the source code text, or an AST. Then the macros have to emit butchered text, or butchered ASTs. Aside from that they are normal perl 6 subroutines, that simply get invoked during compile time instead of during runtime. The AST language (maybe it'll be PIL based) is not yet final, so there's not much to say. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgpjt66A0JBma.pgp Description: PGP signature
Re: Macros?
On 1/29/06, Yuval Kogman [EMAIL PROTECTED] wrote: Aside from that they are normal perl 6 subroutines, that simply get invoked during compile time instead of during runtime. With one extra feature. By default (my preference) or with a trait, parameters can get passed in as ASTs instead of real values: macro debug ($var) { qq[print '$var.text() = ' ~ $var.text()] } debug($foo ); # expands to print '$foo = ' ~ $var ; We would also like a quasiquoting mechanism, so don't have to rely on string concatenation, and we don't have to construct parse trees by hand. It's sort of a happy medium. But that is as yet unspecced. Luke
Re: Macros?
On 29/01/06, Yuval Kogman [EMAIL PROTECTED] wrote: Basically the plan is that when an internal AST language is decided upon, the macros will be able to get either the source code text, or an AST. Two things. First, if the AST path is taken, doesn't that mean that the AST representation has to be compatible between implementations (assuming there'll be more than one)? Secondly, there's ease of use. ASTs are, at least from what I've seen, pretty verbose. Aren't we trying to make things easy for the programmer? With source text, doing manipulations by hand can be a bother, so that's no solution either... Maybe I'm spoiled by the idea of s-expressions, though. But I get the impression that lispy macros are where the idea comes from... -- Schwäche zeigen heißt verlieren; härte heißt regieren. - Glas und Tränen, Megaherz
Re: Macros?
On Sun, Jan 29, 2006 at 20:29:43 +, Herbert Snorrason wrote: On 29/01/06, Yuval Kogman [EMAIL PROTECTED] wrote: Basically the plan is that when an internal AST language is decided upon, the macros will be able to get either the source code text, or an AST. Two things. First, if the AST path is taken, doesn't that mean that the AST representation has to be compatible between implementations (assuming there'll be more than one)? Yes. Secondly, there's ease of use. ASTs are, at least from what I've seen, pretty verbose. Aren't we trying to make things easy for the programmer? With source text, doing manipulations by hand can be a bother, so that's no solution either... Maybe I'm spoiled by the idea of s-expressions, though. But I get the impression that lispy macros are where the idea comes from... Well, the aim is to get something as nice as lisp macros. Hopefully the AST will be easy enough to chew with the tools provided in the language. Remember, however, that this is not a parse tree, and is thus somewhat simpler. BTW, do we also support parse trees? -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sushi-spin-kicks : neeyah pgp2T1llLenSI.pgp Description: PGP signature