On 11/12/2013 01:51 AM, John Clements wrote:
I was looking over changes to Rust recently, and I saw with some alarm that at
least one macro had added an ad-hoc local expansion mechanism. I sat down with
MTWT to see if I could figure out a situation where this might cause a problem.
I came up with something, and I'm hoping that one of you can tell me whether it
makes sense, and whether there are other situations where this comes up.
For what it's worth, the macro in question is one that tries to glue together
strings at expansion time; something like this:
(concat-strings (file-name) ":" (line-number) " there problem is that ~a is not
equal to ~a")
... where (file-name) and (line-number) are macros, and the concat-strings
macro wants to join them all together into a format string that can be
analyzed. In order to perform this analysis, the two sub-macros must be
expanded into strings. It appears to me that syntax-case + compile-time
bindings solves this, but Rust has neither of these.
BTW, this example has an unrelated problem: it reinterprets a file name
as (part of) a format string without any quoting/escaping. If the file
name contains format directives, bad things may happen. I don't know if
that's an issue with the actual macro in question, but beware.
Looking over MTWT, it appears to me that the principal complexity of
local-expand arises from
- stop-lists, and
- un- /re-marking
Looking at Rust, it appears to me that stop-lists are not an issue, at least
for this particular macro. It may be that the marking behavior is also a
non-problem, but I thought I'd try to come up with an example of macros where
it *would* make a difference. The best I got was this:
#lang racket
;; this macro just does a local-expand
(define-syntax (does-local-expand stx)
(syntax-case stx ()
[(_ exp) (local-expand #'exp 'expression #f)]))
(define z 13)
(does-local-expand
(let ()
(define-syntax m
(syntax-rules ()
[(m) z]))
(m)))
So, in Racket, if I understand correctly, the mark from the expansion of
'does-local-expand' is removed (or cancelled) before the syntax-local-expand,
and restored again afterward. The let, on the other hand, generates an instance
of the identifier 'z' that was introduced by the macro 'm', and therefore has
'm's mark on it.
Looking only at the 'z' in the body of the let, then: first it gets a mark m1
upon entry to the expansion of does-local-expand. Then, when the body of
does-local-expand calls local-expand, 'z' gets another m1 mark. Then, in the
expansion of the use of 'm', it gets the mark (call it m2) on the way *out* of
m only (because it wasn't marked on the way into m). Then, the local-expand is
finished, and it gets another m1. Finally, expansion of the use of
does-local-expand is finished, and it gets another m1. So, the end list of
marks is
m1 m1 m2 m1 m1
which is equivalent to just
m2
Now, suppose you *didn't* have the unmarking/re-marking behavior (as currently
Rust does not). In this case, IIUC, you'd wind up with just
m1 m2 m1
which is *not* equivalent to m2.
Right.
> This would then make the 'z' in the definition of 'z' not
bound-identifier=? to the 'z' that's the result of expanding the
'does-local-expand'.
Actually, neither (z with {m2}) nor (z with [m1 m2 m1]) is
bound-identifier=? to (z with {}), but at that point bound-identifier=?
isn't the relevant function; resolve is. In the absence of rename wraps
(introduced by binding forms), both of them resolve to the same z as the
definition, because resolve just throws away marks outside of a rename.
(The resolve function does use bound-identifier=? internally to
determine whether a rename wrap is applicable, but with arguments that
are pieces of the identifiers in question.)
So: did what I said make sense? Is there a more compelling example? Am I right
in suggesting that for this particular macro, it may not make a difference?
Yes, for this particular macro, it shouldn't make a difference.
The extra unmark/remark step matters when binders are involved. For
example, if you local-expand to uncover a definition, then create a
letrec from the definition and another expression in the body that
didn't go through the same local-expand call, then the marks on the
binder will be out of sync with the marks on the references in the body.
Unfortunately, the example that I thought of to illustrate this also
seems to require the special mark-ignoring behavior described at the
very end of Section 3.8 of MTWT.
Here's the example anyway, if you're curious:
;; (le/var var exp) local-expands exp, then puts the result in a
;; let-binding of var to 0
(define-syntax (le/var stx)
(syntax-case stx ()
[(_ var exp)
#`(let ([var 0]) #,(local-expand #'exp 'expression #f))]))
(let ([z 13])
(le/var z
(let ()
(define-syntax m
(syntax-rules ()
[(m) z]))
(m))))
;; => 0 in Racket
Ryan
____________________
Racket Users list:
http://lists.racket-lang.org/users
