Arc Forum | Yes. At runtime. Even ignoring the inefficiency of expanding macros at runtime, ...

Arc Forum

1 point by Pauan 4914 days ago | link | parent

Yes. At runtime. Even ignoring the inefficiency of expanding macros at runtime, there's one other thing that concerns me, and that's anaphoric macros.

If somebody writes a macro like "aif" or "aand" or whatever, you want the variable "it" to refer to the caller's namespace, but all the other variables to refer to the definer's namespace...

I think this is a solvable problem, but I think it'll require more complexity to solve.

By the way, I think I can add in a system where you can selectively choose which variables should be expanded in your namespace, and which ones shouldn't. Something like this:

  (import foo)

  (w/names (it)
    (foo!something))

This says that the variable "it" should be expanded into your namespace, and all other variables should be expanded in foo's namespace.

Interestingly enough, if I implemented such a system, you could then overwrite certain variables in a macro's body:

  (def helper (x)
    (+ x 50))

  (foo!something) -> 15 ; uses foo's version of helper

  (w/names (helper) ; uses my version of helper
    (foo!something)) -> 60

1 point by Pauan 4914 days ago | link

Actually, there's another thing that also concerns me... Consider this macro:

  (def foo args
    (apply prn args))

  (mac bar (x . args)
    `(foo (string ,x) ,@args))

If you call bar, you want the variables "x" and "args" to be expanded in your namespace, but everything else to be expanded in bar's namespace.

-----