如何正确编写含命名符号的宏？解决代码多重求值问题

Let's break down what's going on with your current macro and how to fix it properly.

First, let's clarify: your current code doesn't actually have a multiple evaluation problem—create-object is only evaluated once when the let binding is established. The bigger issue here is resource cleanup reliability: if any code in body uses a non-local exit (like return, throw, or if an error is raised), free-object ,name will never run, leaving your object unclosed and causing a resource leak.

That said, we can also add safeguards to ensure the macro behaves as expected and avoids any potential evaluation-related surprises down the line. Here's the corrected, robust version:

(defmacro with-object (name &body body)
  (check-type name symbol) ; Enforce that `name` is a valid symbol at expansion time
  `(let ((,name (create-object)))
     (unwind-protect
          (progn ,@body)
       (free-object ,name))))

Let's walk through the key changes: #

• check-type name symbol: This runs when the macro is expanded (not at runtime), making sure the user passes a symbol (like obj or my-resource) as the name parameter. This prevents accidental expressions from being passed here, which could lead to broken or unexpected expansion behavior.
• unwind-protect: This is Common Lisp's core tool for reliable cleanup. The body of code ((progn ,@body)) runs normally, but no matter how it exits—whether it finishes successfully, returns early, or throws an error—the cleanup form ((free-object ,name)) will always execute. This fixes the resource leak risk in your original code.
• progn around ,@body: If your body contains multiple forms, progn ensures they're evaluated in order, and the value of the last form in body is returned as the result of the entire with-object form—just like your original macro intended.

Why your original macro fell short: #

Your initial code runs ,@body followed by free-object, but if body uses a non-local exit (e.g., bailing out of a function early with return-from), the cleanup line gets skipped entirely. unwind-protect solves this by registering the cleanup code with the Lisp runtime, guaranteeing it triggers on any exit from the protected block.

If you were ever facing a true multiple evaluation scenario (like an expression being evaluated multiple times in the macro expansion), the fix would involve capturing the value once in a let binding—but that's not the case here. The critical improvement here is making sure your object always gets cleaned up, no matter what happens in the body.

内容的提问来源于stack exchange，提问作者user3496846