On Sun, Jan 29, 2006 at 08:13:44PM +0000, Luke Palmer wrote:
: 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.
S06 now sez:
+=head2 Macros
+Macros are functions or operators that are called by the compiler as
+soon as their arguments are parsed (if not sooner). The syntactic
+effect of a macro declaration or importation is always lexically scoped,
+even if the name of the macro is visible elsewhere. As with ordinary
operators,
+macros may be classified by their grammatical category. For a given
grammatical
+category, a default parsing rule or set of rules is used, but those rules
+that have not yet been "used" by the time the macro keyword or token is seen
+can be replaced by use of "is parsed" trait. (This means, for instance, that
+an infix operator can change the parse rules for its right operand but not its
+left operand.)
+
+A macro is called as if it were a method on the current match object returned
+from the grammar rule being reduced.
+
+Macros may return either a string to be reparsed, or a syntax tree
+that needs no further parsing. The textual form is handy, but the
+syntax tree form is generally preferred because it allows the parser
+and debugger to give better error messages. Textual substitution
+on the other hand tends to yield error messages that are opaque to
+the user. Syntax trees are also better in general because they are
+reversible, so things like syntax highlighters can get back to the
+original language and know which parts of the derived program come
+from which parts of the user's view of the program.
+
+In aid of returning syntax tree, Perl provides a "quasiquoting" mechanism
+using the keyword "code", followed by a block intended to represent an AST:
+
+ return code { say $a };
+
+[Conjecture: Other keywords are possible if we have more than one AST type.]
+
+Within a quasiquote, variable and function names resolve first of all
+according to the lexical scope of the macro definition, and if unrecognized in
+that scope, are assumed to be bound from the scope of the macro call
+each time it is called. If they cannot be bound from the scope of
+the macro call, a compile-time exception is thrown.
+
+Variables that resolve from the lexical scope of the macro definition
+will be inserted appropriately depending on the type of the variable,
+which may be either a syntax tree or a string. (Again, syntax tree
+is preferred.) The case is similar to that of a macro called from
+within the quasiquote, insofar as reparsing only happens with the
+string version of interpolation, except that such a reparse happens at
+macro call time rather than macro definition time, so its result cannot
+change the parsers expections about what follows the interpolated variable.
+
+Hence, while the quasiquote itself is being parsed, the syntactic
+interpolation of a variable into the quasiquote always results in
+the expectation of an operator following the variable. (You must
+use a call to a submacro if you want to expect something else.)
+Of course, the macro definition as a whole can expect whatever it
+likes afterwards, according to its syntactic category. (Generally,
+a term expects a following postfix or infix operator, and an operator
+expects a following term or prefix operator.)
+
+In case of name ambiguity, prefix with C<COMPILING::> to indicate a name in
+the compiling scope, and C<OUTER::> to indicate a name in the macro
definition's
+scope.
+
+[Conjecture: Due to these dwimmy scoping rules, there is no need of
+a special "unquote" construct as in Scheme et al.]
Larry
