From: =?ISO-8859-2?Q?Marko_Koci=E6?=
Subject: Clojure style defmacro in CommonLisp
Date: 
Message-ID: <746cfd6e-04ca-49e0-8987-a944b7a74da8@z9g2000yqi.googlegroups.com>
Is it possible to create clojure style defmacro in common lisp? Has
anyone already attempted to create one?

By clojure style defmacro I think of defmacro equivalent which has
automatic gensyms for symbols ending with #, and autoresolving symbol
names to namespace/symbol when creating macro.

Marko

From: Pillsy
Subject: Re: Clojure style defmacro in CommonLisp
Date: 
Message-ID: <a0f0ec9d-b9a0-4165-9ba8-03169bb62d0b@s20g2000yqh.googlegroups.com>
On Mar 16, 7:20 am, Marko Kociæ <···········@gmail.com> wrote:

> By clojure style defmacro I think of defmacro equivalent which has
> automatic gensyms for symbols ending with #,

Doug Hoyte shows how to do something similar in Chapter 3 of /Let Over
Lambda/, which is available online at

http://letoverlambda.com/index.cl/guest/chap3.html

Check out "defmacro!".

> and autoresolving symbol names to namespace/symbol when creating macro.

If you just want to see fully-qualified names when you macroexpand
things, just bind *package* to the keyword package before printing the
results, like so:

(let ((*package* (find-package :keyword)))
  (pprint (macroexpand-1 '(my-cool-macro a-sweet-argument))))

If you mean the interning behavior of Clojure's backquote, then I
doubt anyone has done anything like that. There really isn't a whole
lot of point in Common Lisp.

Cheers,
Pillsy
From: Marcus Breiing
Subject: Re: Clojure style defmacro in CommonLisp
Date: 
Message-ID: <rxl7pus263jep@breiing.com>
* Pillsy

> If you mean the interning behavior of Clojure's backquote

Actually both features mentioned by the OP are features of the
backquote reader, not defmacro.

I suspect the OP would profit from learning more about the reader, how
reading is not macroexpansion, what's happening when &c., before
returning to his current worry.
From: Kaz Kylheku
Subject: Re: Clojure style defmacro in CommonLisp
Date: 
Message-ID: <20090324164331.966@gmail.com>
On 2009-03-16, Marko Kocić <···········@gmail.com> wrote:
> Is it possible to create clojure style defmacro in common lisp? Has
> anyone already attempted to create one?

Fine-grained interning control at read time:

http://paste.lisp.org/display/72068

With the ·@ syntax in front of a form, you can take various useful package and
interning related actions on the granularity of a single form:

·@((keep foo)(unique a b c))
(defmacro foo (x y z)
  `(let ((a ,x) (b ,y) (c ,z))
     ...))

Here the ·@ is followed by a compound directive list consisting of
(keep foo) and (unique a b c)). 

Firstly, note that the processing of this list itself does not cause these
names to be interned anywhere, similarly in concept to how like #c(2 3) does
not intern the symbol named "C".

The directive (keep foo) means the following form (i.e. the defmacro), will
intern only the symbol FOO into the surrounding package. No other symbols will
be interned. So in other words, the only enduring package-related effect of the
defmacro from will be that the symbol FOO is introduced, if it does not
already. The form contains the symbols X, Y and Z in addition to FOO. Because
these are not on the keep list, they are not propagated to the surrounding
package if they are newly interned. If they are already present or visible in
the package, then they are used, just like CL:DEFMACRO is used.

The directive (unique a b c) means that the symbols A, B and C, occuring in the
form which follows, are unconditionally unique. This means that even if these
symbols have already been interned in the surrounding package, they will be
unique symbols in that form. Any mention of A, B or C in the form has nothing
to do with an existing A, B or C. But of course multiple occurences of A within
the form are all the same symbol!  So this (unique a b c) form is just like as
if you had a #a #b #c read syntax over the scope of that form denoting unique
symbols. The difference between ·@(unique a b c) (... a b c) and (.. #a #b #c)
is analogous to the difference between lambda with explicit parameters, and an
implicit lambda.