Home/ Questions/Q 6206153
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T05:24:02+00:00

Why is the function/macro dichotomy present in Common Lisp? What are the logical problems

  • 0

Why is the function/macro dichotomy present in Common Lisp?

What are the logical problems in allowing the same name representing both a macro (taking precedence when found in function position in compile/eval) and a function (usable for example with mapcar)?

For example having second defined both as a macro and as a function would allow to use

(setf (second x) 42)

and

(mapcar #'second L)

without having to create any setf trickery.

Of course it’s clear that macros can do more than functions and so the analogy cannot be complete (and I don’t think of course that every macro shold also be a function) but why forbidding it by making both sharing a single namespace when it could be potentially useful?

I hope I’m not offending anyone, but I don’t really find a “Why doing that?” response really pertinent… I’m looking for why this is a bad idea. Imposing an arbitrary limitation because no good use is known is IMO somewhat arrogant (sort of assumes perfect foresight).

Or are there practical problems in allowing it?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think that Common Lisp’s two namespaces (functions and values), rather than three (macros, functions, and values), is a historical contingency.

    Early Lisps (in the 1960s) represented functions and values in different ways: values as bindings on the runtime stack, and functions as properties attached to symbols in the symbol table. This difference in implementation led to the specification of two namespaces when Common Lisp was standardized in the 1980s. See Richard Gabriel’s paper Technical Issues of Separation in Function Cells and Value Cells for an explanation of this decision.

    Macros (and their ancestors, FEXPRs, functions which do not evaluate their arguments) were stored in many Lisp implementations in the symbol table, in the same way as functions. It would have been inconvenient for these implementations if a third namespace (for macros) had been specified, and would have caused backwards-compatibility problems for many programs.

    See Kent Pitman’s paper Special Forms in Lisp for more about the history of FEXPRs, macros and other special forms.

    (Note: Kent Pitman’s website is not working for me, so I’ve linked to the papers via archive.org.)

    • 0