Brief History

← Prev | ↑ Chapter | Next → | Index | Symbols

Brief History

The historical genealogy of AutoLISP / Visual LISP shapes several otherwise-arbitrary corners of the language. The chapter-level normative rules — Lisp-1 semantics, dynamic scope, silent-NIL on unbound reference, no tail-call optimization, no multiple values, upper-case folding — are downstream consequences of the choices made by the implementations enumerated below.

  • XLISP (David Betz, 1980s). AutoLISP was derived from a slimmed XLISP. XLISP itself targeted personal computers as a compact, embeddable Lisp dialect with a single-cell symbol model and dynamic scope. AutoLISP inherited that core.
  • AutoLISP shipped in AutoCAD 2.18, January 1986. Released as Autodesk's API for customising AutoCAD. Successive AutoCAD releases extended it through to Release 13 (February 1995).
  • Vital LISP (Basis Software). A third-party superset of AutoLISP adding an IDE, debugger, compiler, ActiveX (COM) bindings, reactors, and additional general-purpose Lisp functions.
  • Visual LISP (Autodesk, 1997). Autodesk acquired Vital LISP and rebranded it. Initially shipped as an add-on to AutoCAD R14.
  • Merger into AutoCAD 2000 (March 1999). Visual LISP replaced the standalone AutoLISP runtime and IDE inside AutoCAD. From this point onward, "AutoLISP" and "Visual LISP" name the same runtime; the documentation distinguishes "core" AutoLISP from the Visual LISP extensions (vl-*, vla-*, vlax-*, vlr-*, etc.).
  • BricsCAD AutoLISP. Bricsys's BricsCAD product implements AutoLISP and large parts of Visual LISP from scratch as a vendor-independent compatibility layer. BricsCAD V25 introduced lax-mode tokenizer and atof extensions; V26 (this work's reference target) preserves them. Bricsys maintains its own bug tracker and release notes; defects such as SR44723 are normative-grade evidence for behaviours that Autodesk's reference is silent on.
  • clautolisp (this project). A Common-Lisp-based reimplementation of the AutoLISP runtime designed to match the Lisp-1, dynamically-scoped, host-product-conformant semantics documented in this specification.

The genealogy explains, among other things, why lambda produces a function value but does not lexically capture (XLISP roots), why integer division truncates (C-influenced numerics from PC-era XLISP), and why values does not exist (the XLISP core never had it).

Source Notes