[dherman]

> Clojure does not have these issues: when the macro is called, the symbols are already attributed with the full namespace qualification, and usage of quasi-quote inside of the macro definition will also apply namespace qualification to variables local to the definition of the macro; you have to go out of your way to break this.

Again, not a Clojure expert, but a namespace is coarser-grained than individual local scopes, right? The problem I'm talking about is when you have a local variable inside a nested scope (e.g. inside a `let`). If this is not named by a namespace, then you would still get collisions.

Regardless, Clojure's approach seems to be much closer in spirit to a hygienic macro system: it attempts to get scoping correct by default, and allows you to intentionally capture.

> You should spend more time looking into it before claiming to people that it doesn't work correctly; you could easily have just said "that's a good question, we'll look into that after the talk" rather than telling the person that Clojure wasn't as good.

Fair enough as far as it goes. I did react snappily, but you didn't hear the offline conversation (this whole thing was a dialog at my office with a friend and colleague, incidentally) where I said "I'm not entirely sure, but I believe there are things you just can't express with systems like Clojure's." And we concluded, just as you reprimanded me to do, that we should look into it further when we have time.

Dave

[saurik]

Correct: I did not hear the private conversation. I only heard the talk that was made public along with this project that was posted here, and which was recommended as an information source, and pretty much serves as the web page and documentation for this project ;P.

> Again, not a Clojure expert, but a namespace is coarser-grained than individual local scopes, right? The problem I'm talking about is when you have a local variable inside a nested scope (e.g. inside a `let`). If this is not named by a namespace, then you would still get collisions.

Ok, so are you are concerned with the case where the person defining the macro uses a symbol from the namespace of the person using the macro but that symbol has been rebound by the user inside of a let surrounding the aforementioned usage of the macro?

If so, that requires a cyclic module dependency, which isn't allowed (as the namespace from which you are getting the symbol would need to be required, but it would have to require back to get access to the macro: it does eager name binding, so that can't happen).

If not, and you are just talking about the simpler and more obvious case of a let shadowing a binding inside of a larger scope used by a macro, that works fine. The following code prints "1100", despite the macro expanding to multiple uses of the same symbol "t".

    (def t 1000) 
    (defmacro run [x] 
        `(+ ~x t))
    (let [t 100] 
        (prn (run t)))

You might then wonder (as I have) whether this is implemented by simply renaming the variables bound by let to something random: that would be sufficient to implement this. However, if I go out of my way to unquote an unqualified symbol, I can capture: the following code prints "1200".

    (def t 1000)
    (defmacro run [x]
        `(+ ~x t ~'t))
    (let [t 100]
        (prn (run t)))

[dherman]

> Ok, so are you are concerned with the case where the person defining the macro uses a symbol from the namespace of the person using the macro but that symbol has been rebound by the user inside of a let surrounding the aforementioned usage of the macro?

> If so, that requires a cyclic module dependency...

Not necessarily. For example (forgive the Scheme syntax), all in one module:

    (define thing "outer thing")
    ;; define-inline is the above macro-defining-macro
    (define-inline (foo prefix)
      (string-append prefix thing))
    (let ((thing "inner thing"))
      (foo "should say outer thing: "))

[saurik]

That seems to be my "if not," case, which I provided some examples for; if this is different, can you please be more explicit? It seems like your "thing" is my "t" and your "foo" is my "run": the only difference is then that I went out of my way to make it more complex my passing the inner thing through the macro to demonstrate it wouldn't get mangled.

    (def thing "outer thing")
    (defmacro foo [prefix]
        `(str ~prefix thing))
    (let [thing "inner thing"]
        (prn (foo "should say outer thing: ")))

"should say outer thing: outer thing"

(edit:) Alternatively, maybe you are focussing on the define-inline "macro-defining macro"; you mentioned it here again as "the above", and you had used it above, but as it wasn't defined it didn't seem important. I tried to go ahead and implement it, although to be honest I feel like I did it wrong (spending more time thinking about it, I believe it is correct, modulo your definition of "inline"); that said, it "worked".

    (defmacro def-inline [[name & args] code]
        `(defmacro ~name ~(apply vector args)
            ~code))

    (def thing "outer thing")
    (def-inline [foo prefix]
        (str prefix thing))
    (let [thing "inner thing"]
        (prn (foo "should say outer thing: ")))

"should say outer thing: outer thing"

[dherman]

Interesting. I don't see how this works. I wonder, is it different if you do this?

    (let [thing "outer thing"]
      (defmacro foo [prefix]
          `(str ~prefix thing))
      (let [thing "inner thing"]
          (prn (foo "should say outer thing: "))))

Dave

[saurik]

That is not possible as written, because the "defmacro" is not executed to define the macro until after the outer let is already executing, which is after macro expansion of that form (and thereby its children), as it has already been read: so what I get for that is a really weird error that I'm passing too many arguments to "foo", as if it were a function (which it is not; albeit I'm not certain what it is ;P).

However, I can use the def-inline that I wrote in the edit to my earlier reply to demonstrate that if you reorganized this code in a way that was semantically equivalent but hoisted the macro, it would work the way you think it should: the definition of the thing from the let surrounding the macro-ish definition is used, not the one from the call site (or the global one in the namespace).

    (defmacro def-inline [[name & args] code]
        `(defmacro ~name ~(apply vector args)
            ~code))

    (def thing "outer thing")
    (let [thing "middle thing"]
        (def-inline [foo prefix]
            (str prefix thing)))
    (let [thing "inner thing"]
        (prn (foo "should say middle thing: ")))

"should say middle thing: middle thing"

(edit:) Oh, that wasn't semantically equivalent, as the second let is not inside of the first. However, if I do that, I get the same behavior as I get in the other case (that it doesn't actually expand the macro at all and treats the form as a function call), as I'm obviously just defining the macro again inside of the same already-read form in which I'm using it.

(further:) Okay, and the reason why that is working is that the way I wrote def-inline inlined the code from def-inline into the macro itself. That is probably not what you wanted from def-inline: this is more like def-const (or def-static or something). I thereby tried doing this instead:

    (let [thing "middle thing"]
        (defmacro foo [prefix]
            `(str ~prefix thing)))
    (let [thing "inner thing"]
        (prn (foo "should say middle thing: ")))

This, in fact, does not return the "correct" string: instead, it fails to work at all, as the "thing" used inside of the macro is supposedly not defined (and worse, if I have a global def for "thing", I get that value). So, this is is a case where the macro is unable to use bindings that are local to the time when the macro definition is executed: it can only deal with global-ish names.

For the record, I think that is unrelated to what I normally think of with relation to hygiene: the macro is able to modify the code using it without accidental capture, but humorously it, itself, is unable to take advantage of symbols that have been bound locally around it. I totally accept that this is probably a flaw (I only say "probably" as I'm willing to believe someone from Clojure can convince me otherwise; it certainly seems like a flaw, though).

(more:) I am increasing the weight of that "probably", as I'm noting that the person calling this code has absolutely no way to refer to the thing that I have access to: there is no path no matter how complex or awesome that would let it refer to my "middle thing". I can inline it with ~, but then it isn't a binding anymore; however, that's actually equivalent, as Clojure does not have setf: "thing" is a constant, and so even if I had a function inside of this let closed over that thing, I couldn't modify its value.

[dherman]

I'd forgotten about the whole Lisp tradition of expanding + evaluating one form at a time -- once again betraying my Scheme biases. :) That's making it hard for me to think about how to compare the two. I'm really not familiar enough with the one-form-at-a-time approach.

Anyway, my takeaways here are:

- I shouldn't've said anything about Clojure specifically, because a) the design space is different and b) they have some form of hygiene-like something-or-other that I don't know enough about. Gotta go study them!

- I still don't know how to do hygiene in Scheme-like languages any other way than the approaches I've seen, but I do agree they're more complicated than I wish they were.

Dave