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 
+macros may be classified by their grammatical category.  For a given 
+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 
+[Conjecture: Due to these dwimmy scoping rules, there is no need of
+a special "unquote" construct as in Scheme et al.]


Reply via email to