(defmacro aif (test-form then-form &optional else-form)
  `(let ((it ,test-form))
     (if it ,then-form ,else-form)))

;;; example
(aif 5
  (print it))

Now, it works fine if the macro definition and expansion are done in
the same package, but falls on its face when not:

;;; package 1 with the macro def
(cl:defpackage "P1"
  (:use "COMMON-LISP")
  (:export "AIF"))

(in-package "P1")

(defmacro aif (test-form then-form &optional else-form)
  `(let ((it ,test-form))
     (if it ,then-form ,else-form)))

;;; package 2 that uses the macro
(cl:defpackage "P2"
  (:use "COMMON-LISP")
  (:use "P1"))

(in-package "P2")

;;; example
(aif 5
  (print it))

Loading this file in clisp (v2.27) results in:
*** - EVAL: variable IT has no value
and macroexpand-1 says that (aif 5 (print it)) is expanded to:
(LET ((P1::IT 5)) (IF P1::IT (PRINT IT) NIL))

P1::IT???
If I do a 'compile-defun-lisp' by hand in emacs for all toplevel
s-exps it works.

What did I do wrong?

  (defmacro when-let ((var test-form) &body body)
    `(let ((,var ,test-form))
       (when ,var ,@body)))

  ;; Example:
  (when-let (it (hairy-computation))
    (print it))

  You used a poorly designed feature.

  The key here is to get a short-hand for

(let ((expr (whatever)))
  (when expr
    (something-using-expr)))

  but in the tradition of really badly designed languages, an implicit
  binding is used instead of doing explicit bindings in the Common Lisp
  tradition, which would also allow more than one binding/expression.

  I would much prefer a syntax like this:

(whereas ((expr-1 (whatever-1))
          (expr-2 (whatever-2)))
  (something-using-expr-1-and/or-expr-2))

  Reading it like the standard contract legalese, the key idea is that all
  prior forms are true when an expression in the binding forms is evaluated
  (just like the operator `and´) and prior variable are bound to the (true)
  value of each prior expression.  The body is an implicit `progn´ that can
  thus rely on all of these forms having non-nil values.

  Having exhausted all useful things to do, I, too, have been thinking about
  how to do bindings and declarations more conveniently, and, not being the
  least bit afraid of parentheses, have decided on binding forms that have
  the general structure

(var-list [expression [decl-list]])

  where var-list is a designator for a list of (symbols naming) variables,
  expression may return multiple values bound to those variables with the
  standard nil default, and decl-list is a designator for a list of types.
  To be gratuitously super-clever, if the type of a variable in `whereas´
  is an explicit union of `null´ and something else to signal that `nil´ is
  a valid value, the result of the test is that using the succeeding value
  (etc by induction) and if it is the last value, the entire form is used
  for bindings, only.  Some examples may yet have a slightly illuminating
  effect:

(whereas (((value present-p) (gethash ...) ((or null ...))))
  ;; value is now actually obtained from the hashtable
  ...)
= (multiple-value-bind (value present-p) (gethash ...)
     (declare (type (or null ...) value))
     (when present-p
       ...)))

(whereas ((index (position ...) fixnum))
  ;; index now holds a fixnum index of an element actually in the sequence
  ...)
= (let ((index (position ...)))
    (when index
      (locally (declare (fixnum index))
        ...)))

(whereas ((cell (assoc ...) cons)
          (value (cdr cell)))
  ;; cell now holds an actually matching cons cell from the alist
  )
= (let ((cell (assoc ...)))
    (when cell
      (locally (declare (cons cell))
        (let ((value (cdr cell)))
          (when value
            ...)))))

  My `let´ and other binding forms parallel this development with a final
  (additional) argument that is the declared types, and allow a list of
  variables for binding multiple values.  Required arguments in lambda
  lists may be typed just like methods on generic functions.  The amount of
  effort to get this done is surprisingly small, and making it fully
  backward-compatible is almost easier than breaking things.

  Please remember that the purpose of this stunt is to give people a good
  reason to stay away from ill-designed and very un-Common-Lispy ways of
  "improving" on the language.  Macros that bind things and which neither
  work when nested nor when naïvely exported in the package system may
  appear "cool" to people who come from other languages, but not to the
  seasoned users.  Just like some may believe that "then" and "else" have a
  place in `if´ "statements" because the language they /really/ want to use
  does that, misguided attempts annoy people more than benefit a community.

--
Erik Naggum, Oslo, Norway

Briefly, the 'IT' is seen by the reader and turned into a
symbol in the P1 package by the reader (because you did an
'in-package' to P1).  The defmacro 'really' looks like

(lisp::defmacro p1::aif (...)
  `(lisp::et ((p1::it ,p1::test-form))
   ...
   )

after it is read in.  

The 'IT' in (aif 5 (print it)) after you do (in-package "P2")
is likewise really p2::it, and these two symbols have
absolutely nothing to do with one another.

Does this help?

Did you really want to master packages and macros at /the same time/?
Brave soul! :)

If so, its simple: symbols "coded" by a macro, while reasonably viewed
to be expanded into the code where the macro is coded, do /not/ in fact
invade the namespace of a /different/ package of the code referencing
the macro, as would code actually written there.

So by default "it" does not invade the namespace of package P2. Even if
P2 "uses" P1. But! If P1 exports "it", the body of code provided to AIF
will "see" the "it" provided by p1.

[1] I have no idea why an emacs compile-defun-lisp
  "trick" makes it work, i don't happen to do emacs. i do know truly
interpreted shit works where compiled doesn't (why I do not know) so
maybe you are in this area.

--

:)

--

  (vars-form [expression [&rest declarations]])
  vars-form ::= var | var-list
  var-list ::= (var-name ...)
  var-name ::= var | (var type)

Which is a little more complicated to implement, but pretty much the
same idea.  It makes type declarations easier than others, because I
use them far mor often than any other type of declaration.  I think
this form is even less for those afraid of parens, though:

  (tfb:let. ((((x integer) (y some-type)) (compute-values))
             (((z number)) (compute-more)))
    (foo x y z))

Note that ANSI CL itself already contains some anaphora:

        (let ((list '(nil (a b) nil (c d e) nil (f g h i) (j k l))))
          (loop for i in list
            when (third i)      ; pun intended.
             collect it))
        => (E H L)

-Rob

And as a side-effect (should be avoided, I know :-)), anaphoric macros
lost some of their allure.

This is what makes it possible to write them as keywords (in another
sense of the word...), something that makes them stand out nicely
(with font-lock, anyway)..

Cheers,
M.

Kind regards,