Re: semantics of ?=

[Keith Playford <address@hidden>]

Re: the semantics of ?= and the ambiguity of "the lexical context
where the macro was called", I recall it was discussed when the macro
system was being designed. If I remember correctly, I raised similar
misgivings about ?= causing the behaviour of code to change just
because it was moved into a macro template.

Bottom line is that ?= as-is is a relatively simple mechanism that
probably gives the most bang for your buck in terms of utility. Other
approaches get a lot more complicated, and we just ran out of time to
work them out to our satisfaction.

I agree with Bruce that, ideally, a template should be considered to
be a call point with equal status to non-template code. But in
practice:

  o Formally, what defines the origin of a macro call? In macro
    systems with statically-typed templates you can probably work that
    out, but Dylan's more liberal than that and all you have is a
    stream of tokens that may have mixed origins. The approach to this
    in some of the Scheme macro systems was to use the macro name in
    the call as the anchor, but it's not clear that that's wholly
    satisfactory. Consider:

    => { define ?foo (x) return(x + 1) end }

  o If your anti-hygiene operator only exposes its names to references
    textually at the macro call point, you will need additional
    mechanism to allow the caller to "re-export" these to its caller.
    Consider:

    // A loop that binds a break function
    define macro loop
      { loop ?:body end } => { block (?=break) while (#t) ?body end end }
    end macro

    // An enhanced loop that adds a continue function
    define macro loop++
      { loop++ ?:body end } => { loop block (?=continue) ?body end end }
    end macro;

    How do you annotate the call to loop in the loop++ template to
    indicate that "return" should be made visible to loop++'s callers?

    Perhaps it's enough to enforce the design discipline that any
    macro that exports a binding should allow the bound variable name
    to be optionally declared somewhere in its syntax, giving the
    caller control (e.g. #next in "define method"). Then again, what
    if the inner macro exports a whole host of names and you don't
    want to have to know them all?

There's plenty to look into here if someone's interested. Consider
also the semantics of keyword matching, by which I mean how syntax
markers like "exception" or "finally" or "slot" are handled. What if I
implement "loop" in terms of "for", but want to hide "finally" from
loop's callers? I get away with it because, typically, I bind to a
constraint like ?:body, rendering the input atomic wrt matching, but
can all examples be avoided that way? Shouldn't hygiene rules apply
there too like they do in some Scheme systems?

-- Keith