I've been thinking too that there must be a better way to deal with all these "(name (...args...) . body)" macros, although I've been approaching it from a different direction. The "macro for decorating body" design pattern is happening so often, it makes me feel something is wrong.
For instance, in srv.arc, 15 out of 16 macros are of the form "... ,@body ..." Macros seem a heavyweight way of doing this sort of #define-style replacement. Another thing that bothers me is that it's impossible to tell without examining the macro what gets evaluated immediately, what gets evaluated as part of the macro expansion, and what gets evaluated at some later time, for example in:
(w/link-if (prn 1) (prn 2) (prn 3) (prn 4))
There's no way to tell when these four expressions are evaluated without digging through the w/link-if code. There's also no way to tell which expressions are logically grouped together.
Arc has several innovative new syntaxes. It seems as if there must be some better new syntax for handling body macros, and Arc should provide it. Surely Lisp's syntax isn't the 100-year answer.
as far as I can tell, `(insert your macro code here ,@body) is the generalized solution form of that design pattern. Just template the code: insert this part here, insert that part there.
The nice thing about templating is that you reasonably arbitrarily insert various bits of code:
Of course, Arc does indeed try to provide specific, shorter solutions for the most common cases, such as single-argument functions ([... _ ... ] syntax), single-variable 'let (let syntax), and anaphoric macros.
Perhaps we can define mac-sym?
(mac-sym foob
'(insert your code here))
(foob
niaw
woof
arf)
==
(insert your code here
niaw
woof
arf)
(mac mac-sym (name . body)
(w/uniq m-body
`(mac ,name .m-body
(join (do ,@body) ,m-body))))
Or is what is bothering you something else entirely?
