## A New Realization about Common LISP

In This Posting, I explored the potential fact in great depth, that certain implementations of LISP may have Symbols, one field of which holds a value in the sense that a variable should hold a value, consisting of lists and atoms, while another field can hold a property list, also known as a “Symbol Plist”.

Well it has come to my attention, that Common LISP in particular, has some fixed constraints regarding this subject.

When Common LISP evaluates expressions that are lists, the CAR is allowed to be a nested list, which defines a lambda-expression. But otherwise, the CAR needs to be an atom – i.e., a symbol – which has a compiled function, stored in the plist.

We may export function-definitions into the value-field of a symbol, such as into a variable, like so:


(defvar *function-var*
#'(lambda (pos-arg1 pos-arg2)
(list pos-arg1 pos-arg2) ) )



If we do, then we must call or apply this function like so:



(funcall *function-var* 'Foo 'Blatz)

(apply *function-var* '(Foo Blatz) )




If we do not abide by this convention, we get error messages, because the function-definition in the value-field is not searched by Common LISP, when the symbol is itself the CAR of a list, and because when we assign lists as function-definitions, those do not get assigned to the symbol plist.

This observation seems to be corroborated here.

This convention, of Common LISP, accelerates execution greatly, because the interpreter does not need to make complicated arrangements, depending on what type of functions appear as the CAR of a list. The context now specifies that.

Once we are aware that this constraint exists, adapting our value-field-functions to it, is straightforward, because of the built-in function

(symbol-function 'symbol)

Which disembodies the part of the plist, that is supposed to hold functions and not values, in this case, belonging to 'symbol. Hence, the following experiment should succeed on a working Common LISP Compiler:



GCL (GNU Common Lisp)  2.6.12 CLtL1    Oct 28 2014 10:02:30
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>(setf (symbol-function 'my-function)
(lambda (pos-arg1 pos-arg2)
(list pos-arg1 pos-arg2) ) )

(LAMBDA-CLOSURE () () () (POS-ARG1 POS-ARG2) (LIST POS-ARG1 POS-ARG2))

>(my-function 'Foo 'Blatz)

(FOO BLATZ)

>(my-function 'Ergo 'Sum)

(ERGO SUM)

>(quit)




Now, the somewhat unexpected line output from the definition, is due to the (setf) function doing what all variable-setting functions in LISP do: They not only bind the value asked for, to the field, but also return the same value to the calling context, because doing so can make certain LISP code more practical.

## Distinguishing between Atoms and Symbols in LISP

Upon closer examination, it seems that public documentation about LISP cites Atoms as an especially simple example of Symbols, that just have an empty Property List (NIL). It is written that they are first created that way by default.

Otherwise, Symbols are capable of carrying Values, which could just be another Atom, or which could be represented by a List in turn, whose first element is a type-atom.

It seems that in my writings, I have just reversed this use of the terms ‘Symbol’ and ‘Atom’. My main reason for not correcting this, is the fact that it would be too complicated to go back and edit so much.

I apologize for this apparent error, but will stick to it for the sake of consistency.

When Function definitions are written, Atoms and Keywords are given that bear no initial value, and which therefore, according to popular documentation, are not fully Symbols yet. These Atoms would be of no usefulness, if during the Evaluation of LISP expressions, they could not be bound to Values with local scope at least. So any Atom can trivially be promoted to a Symbol.

The other Atoms need to state Functions or Macros.

And in cases where they are type-atoms, their value can be a parent type, again leading to an Atom. So those examples should not have NIL as their Property, because the parent-type for all types, is supposed to be T and not NIL. If a type-atom was to have NIL as its ultimate parent, it would just refer to some unrecognized type, outside the LISP Interpreter scope for how to Evaluate.

Dirk

## An obscure assumption I make about LISP

In order for a single address-field to represent a List, it needs to point to a dotted-pair. But I also assume, that a complex data-type for a Symbol, would be such a pointer, in contrast to how simpler Atoms could just be a pointer to another, single Atom, or NIL.

Dirk

A historic concept about LISP still holds true, that this language stores structures which consist of Lists and Atoms. List are represented in binary as “Dotted Pairs”, with a CAR and a CDR register. The CAR holds the first element of the List, while the CDR holds the tail of the List. It is uncommon but possible, for the CDR also to hold an Atom, while more correctly, a value of NIL in the CDR denotes the end of a List. The CDR function of NIL is defined to be NIL.

( Posting Revised on 09/25/2016 )

( German Translation Revised on 09/25/2016 )

The way in which Atoms are represented in binary, is much more implementation-dependent. In theory, an Atom might only consist of a CAR field. But in technical practice, it is possible for all Atoms to be stored at even-field addresses, and to be associated with CDR-like fields, that would actually be CIR-fields, that are named “Property Lists“. One interesting fact to note, is that while historic versions of LISP made extensive use of these Property Lists, let us say in order to associate the Print-Name of an Atom back from the actual Atom, according to a certain article, “Common LISP” makes very little or no use of explicit Property Lists.

From my own experience, I question this article. For example, the mere fact that the Atom ‘list‘, as referring to the Function, needs to be written #'list , in order to be passed in as an argument, suggests that indeed, its Function-code is stored elsewhere, from its value as an Atom…

While all LISP Versions can process Property Lists defined by the programmer, this posting refers to ones, that were associated with Atoms ‘behind the scenes’. According to the article above, in modern versions of Common LISP, the latter type can no longer be derived from an Atom, as its “Disembodied Property List”.


GCL (GNU Common Lisp)  2.6.12 CLtL1    Oct 28 2014 10:02:30
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>list

Error: UNBOUND-VARIABLE :NAME LIST
Signalled by EVAL.
UNBOUND-VARIABLE :NAME LIST

Broken at EVAL.  Type :H for Help.
>>1

Top level.
>(get 'list)

Error: PROGRAM-ERROR "GET [or a callee] requires more than one argument."
Signalled by GET.
PROGRAM-ERROR "GET [or a callee] requires more than one argument."

Broken at GET.  Type :H for Help.
>>1

Top level.
>(get 'list 'name)

NIL

>(get 'list 'type)

NIL

>(defvar *my-list* '(foo blatz bar))

*MY-LIST*

>(get '*my-list* 'name)

NIL

>(get '*my-list* 'type)

NIL

>(get '*my-list* 'value)

NIL

>*my-list*

(FOO BLATZ BAR)

>(symbol-plist 'list)

(COMPILER::INLINE-ALWAYS
(((T T T T T T T T T T) T 1 COMPILER::LIST-INLINE)
((T T T T T T T T T) T 1 COMPILER::LIST-INLINE)
((T T T T T T T T) T 1 COMPILER::LIST-INLINE)
((T T T T T T T) T 1 COMPILER::LIST-INLINE)
((T T T T T T) T 1 COMPILER::LIST-INLINE)
((T T T T T) T 1 COMPILER::LIST-INLINE)
((T T T T) T 1 COMPILER::LIST-INLINE)
((T T T) T 1 COMPILER::LIST-INLINE)
((T T) T 1 COMPILER::LIST-INLINE) ((T) T 1 "make_cons(#0,Cnil)")
(NIL T 0 "Cnil"))
COMPILER::RETURN-TYPE T COMPILER::ARG-TYPES (*) COMPILER::LFUN
"Llist" SYSTEM::TYPE-PREDICATE LISTP)

>(symbol-plist '*my-list*)

NIL

>(quit)




What follows is an area in the implementations of LISP, which documentation tends to dance around. What documentation writes about extensively, is how Variables exist in LISP, and how different types of Variables can be used – within the text-syntax of LISP itself. It is important to note, that being able to map Variable-Names to values, is more important than the reverse. I.e., code can name Variables and thus Atoms, such that data structures result, and the Atoms that result within the data structures can be bound to new values rapidly, as LISP is being interpreted. The values of the resulting computations need to be output. But the need is not as strict, for Atoms to be reprinted by their names rapidly.

Further, many types of values associated formally with Variables, can in fact be represented either entirely within one Field, or as Lists again, such that Strings, arbitrary-length Integers etc., can all be printed out easily, starting from Atoms.

Variables are not said to be typed, but rather the objects they point to are. And LISP is said to be strongly typed, in that operations are always forbidden, when attempted on illegal data-types. A “Type-Error” will be generated reliably at run-time, for example, if an attempt is made to evaluate (+ 5 "David") , because "David" is not a number.

It would seem clear, that the fastest test which a LISP Interpreter needs to perform on a value, is whether it references a List or an Atom. And when an attempt is made to Evaluate an Atom, the next question which the interpreter needs to answer, is what data-type is stored in the Atom, to determine whether the instructed operation is in fact legal.

1. Since Lists consist of Dotted Pairs, addresses that point to them are bound to point to an even-numbered Address Field Address, if the CDR-field address is derived by incrementing. Originally, the CDR-field was found by decrementing, which gave rise to its name: “Complement Decrement Register”. So then, a pointer to a List would always have pointed to an odd-numbered Address Field, either way because it always pointed to the CAR. Pointing to an alternately-numbered one – to where a CDR would occur in a List – could signal to the Interpreter, that an Atom is being referenced. While this approach only requires that one bit be examined, to reveal whether the current address points to a List or an Atom, the main drawback would be, that whether a value is either, derives only from the Cell which is pointing to it. Some confusion could start, in which certain address fields point to an object as a List, but in which others point to the same objects, potentially, as an Atom. At that point, the binary image might have gotten corrupted, in a way that can easily happen.
But then this would also imply, that every allocated block is an MMAP Object. This might make more sense on a 64-bit machine, where 48-bit look-up tables are impossible. Instead, the size of allocation blocks could be increased to ~1MB, to reduce the number of MMAP Symbols.