At the heart of the Lisp interpreter is its management of objects.
SXEmacs Lisp contains many built-in objects, some of which are
simple and others of which can be very complex; and some of which
are very common, and others of which are rarely used or are only
used internally. (Since the Lisp allocation system, with its
automatic reclamation of unused storage, is so much more convenient
than malloc() and free(), the C code makes extensive use of it
in its internal operations.)
The basic Lisp objects are
integerfloatconschareq,
which makes a special exception and considers a char to be eq to
its integer equivalent, even though in no other case are objects of two
different types eq. The reason for this monstrosity is
compatibility with existing code; the separation of char from integer
came fairly recently.)
symbolvectorstringbit-vectorcompiled-functionsubrNote that there is no basic “function” type, as in more powerful
versions of Lisp (where it's called a closure). SXEmacs Lisp does
not provide the closure semantics implemented by Common Lisp and Scheme.
The guts of a function in SXEmacs Lisp are represented in one of four
ways: a symbol specifying another function (when one function is an
alias for another), a list (whose first element must be the symbol
lambda) containing the function's source code, a
compiled-function object, or a subr object. (In other words, given a
symbol specifying the name of a function, calling symbol-function
to retrieve the contents of the symbol's function cell will return one
of these types of objects.)
SXEmacs Lisp also contains numerous specialized objects used to implement the editor:
bufferframewindowwindow-configurationdevicefacemarkerextenteventnext-event and contains information
describing a particular event happening in the system, such as the user
pressing a key or a process terminating.
keymapglyphprocessThere are some other, less-commonly-encountered general objects:
hash-tableobarrayspecifierchar-tablerange-tableAnd some strange special-purpose objects:
charsetcoding-systemcolor-instancefont-instanceimage-instancesubwindowtooltalk-messagetooltalk-patterntoolbar-buttonAnd objects that are only used internally:
opaquemalloc() and the convenience of the Lisp object
system.
lstreamchar-table-entryextent-auxiliarymenubar-datatoolbar-datasymbol-value-forwardsymbol-value-buffer-localsymbol-value-varaliassymbol-value-lisp-magic Some types of objects are permanent, meaning that once created,
they do not disappear until explicitly destroyed, using a function such
as delete-buffer, delete-window, delete-frame, etc.
Others will disappear once they are not longer used, through the garbage
collection mechanism. Buffers, frames, windows, devices, and processes
are among the objects that are permanent. Note that some objects can go
both ways: Faces can be created either way; extents are normally
permanent, but detached extents (extents not referring to any text, as
happens to some extents when the text they are referring to is deleted)
are temporary. Note that some permanent objects, such as faces and
coding systems, cannot be deleted. Note also that windows are unique in
that they can be undeleted after having previously been
deleted. (This happens as a result of restoring a window configuration.)
Note that many types of objects have a read syntax, i.e. a way of
specifying an object of that type in Lisp code. When you load a Lisp
file, or type in code to be evaluated, what really happens is that the
function read is called, which reads some text and creates an object
based on the syntax of that text; then eval is called, which
possibly does something special; then this loop repeats until there's
no more text to read. (eval only actually does something special
with symbols, which causes the symbol's value to be returned,
similar to referencing a variable; and with conses [i.e. lists],
which cause a function invocation. All other values are returned
unchanged.)
The read syntax
17297
converts to an integer whose value is 17297.
1.983e-4
converts to a float whose value is 1.983e-4, or .0001983.
?b
converts to a char that represents the lowercase letter b.
?^[$(B#&^[(B
(where ‘^[’ actually is an ‘ESC’ character) converts to a particular Kanji character when using an ISO2022-based coding system for input. (To decode this goo: ‘ESC’ begins an escape sequence; ‘ESC $ (’ is a class of escape sequences meaning “switch to a 94x94 character set”; ‘ESC $ ( B’ means “switch to Japanese Kanji”; ‘#’ and ‘&’ collectively index into a 94-by-94 array of characters [subtract 33 from the ASCII value of each character to get the corresponding index]; ‘ESC (’ is a class of escape sequences meaning “switch to a 94 character set”; ‘ESC (B’ means “switch to US ASCII”. It is a coincidence that the letter ‘B’ is used to denote both Japanese Kanji and US ASCII. If the first ‘B’ were replaced with an ‘A’, you'd be requesting a Chinese Hanzi character from the GB2312 character set.)
"foobar"
converts to a string.
foobar
converts to a symbol whose name is "foobar". This is done by
looking up the string equivalent in the global variable
obarray, whose contents should be an obarray. If no symbol
is found, a new symbol with the name "foobar" is automatically
created and added to obarray; this process is called
interning the symbol.
(foo . bar)
converts to a cons cell containing the symbols foo and bar.
(1 a 2.5)
converts to a three-element list containing the specified objects (note that a list is actually a set of nested conses; see the SXEmacs Lisp Reference).
[1 a 2.5]
converts to a three-element vector containing the specified objects.
#[... ... ... ...]
converts to a compiled-function object (the actual contents are not shown since they are not relevant here; look at a file that ends with .elc for examples).
#*01110110
converts to a bit-vector.
#s(hash-table ... ...)
converts to a hash table (the actual contents are not shown).
#s(range-table ... ...)
converts to a range table (the actual contents are not shown).
#s(char-table ... ...)
converts to a char table (the actual contents are not shown).
Note that the #s() syntax is the general syntax for structures,
which are not really implemented in SXEmacs Lisp but should be.
When an object is printed out (using print or a related
function), the read syntax is used, so that the same object can be read
in again.
The other objects do not have read syntaxes, usually because it does not really make sense to create them in this fashion (i.e. processes, where it doesn't make sense to have a subprocess created as a side effect of reading some Lisp code), or because they can't be created at all (e.g. subrs). Permanent objects, as a rule, do not have a read syntax; nor do most complex objects, which contain too much state to be easily initialized through a read syntax.