I've read and reread the macro explanation but I'm still not entirely
clear on number of things.  The questions and thoughts below are based
on my (mis)understanding.

On 03/02/06 02:05, Larry Wall wrote:
    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.

And presumably they can be lexically unimported, or whatever the verb is
for what "no" does.

    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.)

    In the absence of a signature to the contrary, a macro is called as
    if it were a method on the current match object returned from the
    grammar rule being reduced; that is, all the current parse information
    is available by treating C<self> as if it were a C<$/> object.

Is this a :keepall match object? Or is the Perl6 grammar conserving by default? (The "Syntax trees [...] are reversible" suggests so)
Or is this one of the "signature to the contrary" possibilities?

    [Conjecture: alternate representations may be available if arguments
    are declared with particular AST types.]

    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 };

I guess the string form is C<eval "CODE { $str }">

If CODE may enclose arbitrary source text of whatever DSL poeple invent,
alternate braces would probably be useful.  Either q()-like, HERE-doc
or pod's C<< >> nesting style.

    [Conjecture: Other keywords are possible if we have more than one
    AST type.]

Ocaml and camlp4 are probably a good source of ideas for quasiquoting.
I've only perused the documentation, has one actually used Ocaml here?
See: http://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial004.html

Rather than misrepresenting Ocaml with my sketchy understanding,
I'll just mention some possibly interesting features:

Specific expander rules from the grammar can be used, <:rulename< ... >>

They have a C -> AST expander.  I can imagine a SQL -> AST expander
would find some use in Perl. I don't think the same AST type is used but that's just a guess.

Two of the "p"s in p4 stand for pretty-printer, which is the AST->source
conversion.  In addition to aiding debugging and reformatting, it allows
interconversion between different syntaxes (sp?).  Ocaml comes with two
grammars, one is backwards compatible and the other has jettisoned
the baggage.
    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 parser's expectations about what follows the
    interpolated variable.

Is there any cpp-like protection against self-referential expansions
when using the string returning form?

The last S06 sentence above overflowed my mental stack, so I'm unsure whether self-referential expansions are somehow impossible.

    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.)

Do @arrays of ASTs interpolate/splice?

Lisp needs ,@ (comma-at) to do splatty interpolation, that is remove the
outer pair of parens.  Depending on what the ASTs look like and how they
splice together, such a form may or may not be necessary.

    In case of name ambiguity, prefix with C<COMPILING::> to indicate a
    name in the compiling scope, and anything else (such as C<OUTER::>)
    to indicate a name in the macro definition's scope, since that's the
    default.  In particular, any variable declared within the quasiquote
    block is assumed to scope to the quasiquote; to scope the declaration
    to the macro call's scope, you must say

        my COMPILING::<$foo> = 123;
        env COMPILING::<@bar> = ();
        our COMPILING::<%baz>;

    or some such if you wish to force the compiler to install the variable
    into the symbol table being constructed by the macro call.

"COMPILING" here means the scope in which the macro is being expanded, rather
than the scope in which the macro itself is being compiled, is that correct?

Perhaps a twigil would be clearer?  Such huffmanization is probably
undeserved and would be seen as encouraging promiscuous lexical intercourse...

What are the variable visibility rules when interpolating in quasiquotes?
Does a variable unbound in a spliced AST bind to one in the enclosing quasiquote? The consequences of this when inserting an AST from a parsed parameter need to be considered. If the enclosing quotes variables are visible then an unintended binding may occur.

    [Conjecture: Due to these dwimmy scoping rules, there is no need of
    a special "unquote" construct as in Scheme et al.]

No gensym shenanigans either.  The scoping rules seem to be hygienic,
no unintended variable leaking.  Unintended variable capture seems unlikely
too, only if you forget to declare a variable with the macro declaration
and coincidently declare the same variable in the macro use scope will
everything go haywire.


That one's own district is unsophisticated and unpolished is a great
treasure. Imitating another style is simply a sham. -- Hagakure http://bereft.net/hagakure/

Reply via email to