|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
At the heart of the Lisp interpreter is its management of objects.
XEmacs 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
free(), the C code makes extensive use of it
in its internal operations.)
The basic Lisp objects are
Objects which are not conses are called atoms.
Note that there is no basic "function" type, as in more powerful
versions of Lisp (where it's called a closure). XEmacs Lisp does
not provide the closure semantics implemented by Common Lisp and Scheme.
The guts of a function in XEmacs 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
to retrieve the contents of the symbol's function cell will return one
of these types of objects.)
XEmacs Lisp also contains numerous specialized objects used to implement the editor:
next-eventand contains information describing a particular event happening in the system, such as the user pressing a key or a process terminating.
There are some other, less-commonly-encountered general objects:
And some strange special-purpose objects:
And objects that are only used internally:
malloc()and the convenience of the Lisp object system.
Some types of objects are permanent, meaning that once created,
they do not disappear until explicitly destroyed, using a function such
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.)
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
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
The read syntax
converts to an integer whose value is 17297.
converts to a ratio commonly used to approximate pi when ratios are configured, and otherwise to a symbol whose name is "355/113" (for backward compatibility).
converts to a float whose value is 1.983e-4, or .0001983.
converts to a char that represents the lowercase letter b.
converts to a Han character meaning "south, southwards"; depending on how your XEmacs is configured, it will be assigned to either a Japanese or Chinese character set (possibly even a Korean one).
converts to a string.
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
(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 XEmacs 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).
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 XEmacs Lisp but should be.
When an object is printed out (using
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.
|[ << ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|