I'd love to hear what the difference is between arc macros and scheme hygenic macros that makes one effortless and the other unhelpful.
(defmacro foo (args go here) `(code goes ,here))
Hygiene is a red-herring. It's easy enough to achieve with a defmacro-style macro system - just use gensyms.
> It's easy enough to achieve with a defmacro-style macro system - just use gensyms.
Gensym cannot prevent global identifiers from being shadowed in macro use environment.
(define-macro (my-if a b c) `(if ,a ,b ,c))
(define (boo)
(let ((if list)) ; if is shadowed
(my-if 'x 'y 'z))) ; evaluates to (x y z), not y
(define-macro (my-if a b c) `(std.if ,a ,b ,c))
(define (boo)
(let ((if list)) ; if is shadowed
(my-if 'x 'y 'z))) ; gives (std.if x y z)
(define (boo2)
(let ((std.if list)) ; error! cannot shadow module vars.
(my-if 'x 'y 'z)))
(ps. This ofcourse would not be limited to the languages std module but would also apply to any exported module symbols.)
(mac awhen (expr . body)
`(std.let it ,expr (std.if it (std.do ,@body))))
On the other hand, one of the reasons Scheme avoids explicit module prefix is, I think, that it breaks abstraction. Suppose my-module defines my-macro and my-function. My-macro expands into a call to my-function. But I don't really want my module users to call my-function directly, so I only export my-macro and keep my-function private.
In your proposal, my-macro will expands into prefixed-symbol like this:
(define-macro (my-macro arg) `(my-module.my-function ,arg))
This is a language design choice. Some may not mind others to mess with module-private bindings; CLers certainly would not. But if you want to hide module-private symbols, and want to allow macros expand into them, how will you do that? One idea is to mark the output of macro expansion so that the compiler can distinguish whether the reference is from legitimate macro expansion or not... well, that's what hygienic macro is doing.
In the first point I was asking to be convinced that you can't have hygiene solely through the use of a package / module system and without needing multiple namespaces.
Although your workaround argument (for allowing variables to be shadowed) is convincing, in that case the package system wouldn't really be providing any safety at all and only the convention would be helping. I guess we can sum it up as CLers really don't see a problem at all, and Schemers require macros to be completely abstract.
Hygiene can also be baked-in to a nice lispy defmacro-style system; there's no reason that hygienic macros have to be scheme-style. Variable capture can be permitted with a (capture x) special form. (I like to use ^x as a shorthand for that).
At that point, macros start behaving scope-wise similarly to lexical functions, and captured variables behave kind of like dynamic variables in a function.
It suddenly occurs to me that this form of hygiene could be implemented in the expansion of let, lambda and defun forms, at which point (someone yell at me please if I'm wrong), plain-ol' defmacros would be hygienic, unless there's a type of variable capture that I'm forgetting about right now...
Then there's a macro in Arc, for example,
(mac awhen (expr . body)
`(let it ,expr (if it (do ,@body))))
I imagine that a Scheme programmer who was experienced in writing hygienic macros and so could write them quickly, and who was more bothered by the lack of hygiene than I am, could well reach a different cost/benefit decision than I do and decide they'd rather go with hygienic macros.