Next in our list of Lisp features not necessarily encountered in a brief introduction is export.  This is related to the package system of Lisp.  You may find it useful to review the earlier article on delete-package, to understand what a package is in Lisp, and how it differs from C++ classes and namespaces.

Once again, the use of this function ties back to a fundamental difference in the creation of Lisp programs, as distinct from C++ programs.  In C++, the author edits one or more disc files, compiles them into a single executable unit, and then runs that executable.  If changes are to be made, the programmer edits the disc files once more, recompiles, and then restarts the C++ binary.

Lisp programs, on the other hand, are assembled by inserting code into a Lisp image.  Rather than creating a new stand-alone binary, you should think of this in terms of adding things to a blank Lisp image.  Functions, classes, structure, packages, and more, are added, serially, to a Lisp image in order to achieve a desired program state.  Some of the things that C++ would do with keywords and compiler or linker directives are, in Lisp, done with functions that act at the time of invocation, not at the time of compilation.

So, we mentioned packages earlier, and how they are a bit like namespaces, but have the private/public symbols the C++ programmer might associated with private/public methods in classes.  A symbol in a Lisp package is not exported by default.  To the beginner Lisp programmer, this looks like a small difference, calling those symbols requires using a double-colon after the package name, rather than a single colon.  In the context of package inheritance, however, an exported symbol is visible in derived packages that inherit from it, and exported symbols raise the possibility of namespace collisions in that context.

So, what does export do?  Well, unsurprisingly, it causes a particular symbol to be exported from the package.  Normally, the programmer lists the exported symbols in the package definition, as, for instance, in this earlier article, with the :DL-LIST package.  The implementation of the defpackage macro, however, generally calls export or something of equivalent functionality.  The programmer may have reason to choose to export certain symbols at runtime, for instance if optional packages that would supply those symbols are not loaded.  In most circumstances, this function will be only rarely used.