Common LISP has turned any Function a Symbol holds, into An Additional Field.

I had started to write about this subject some time ago.

This was a posting of mine, in which I pondered the more-general question, of how different LISP variants may recognize, that they have encountered a List or an Atom.

In this posting, I went into the specific question more, of how to use Common LISP, and manipulate the distinction between Symbols that store Functions, and Symbols that store Lists. Obviously, Common LISP requests, that we use the built-in function (symbol-function) to refer specifically to the Function stored within.

And in this posting, I carried out a very basic experiment, to see whether a data-type is stored on the plist, in Common LISP. The answer was No.

I should not even refer to my experiments as such, because they are too rudimentary to qualify. Instead, these are simple efforts to educate myself – and anybody else who might be curious enough to read my blog – about LISP, through Common LISP. Testing the plist of a Symbol, is very straightforward in practice.

I have gone further with the present posting, by just confirming what I already suspected. When we use a Symbol to store a Function, in fact this gets treated separately, and again does not get stored on the plist. The function-field could state that the Symbol stores a Compiled Function, or a List that needs to be Interpreted, according to which blocks of addresses it points to…

What I have noticed however, is that in the case of Predefined, Compiled Functions, meta-data does get stored on the plist, which allows the LISP Compiler to act more, as Compilers do, for languages intended to be procedural in style. LISP was originally intended for declarative-style programming, but to be able to compile each function, it was necessary to standardize the way parameter-lists work, as well as return-types, conform to how they work in procedural languages such as C or C++.

In keeping with that, the plist of a Compiled, Predefined, Common LISP Function, contains templates, that state expected parameter-type-lists, just as C Function-Prototypes would have it.

But what seems to follow, is a flavor of LISP, which does not require the plist, in order for images to execute, and in order to be able to evaluate Lists. They only seem to be needed, to develop images and ‘LISP-Programs’.

The following code block shows, what happened in my most recent session…

Continue reading Common LISP has turned any Function a Symbol holds, into An Additional Field.

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