The Lpp library tries to prevent name space clashes with other libraries so that it can be included with such other libraries. All the identifiers reserved for Lpp fall into one of the four following categories
In case 1 Lpp class and subtype class names are few and
correspond directly with names in the Common Lisp type hierarchy
except that the Lpp class names begin with a capital letter. For
Number for the Lpp number object,
the Lpp Integer object,
String for the Lpp string object, etc.
In case 2 the Lpp library creates its own name space of
functions that dispatch on the
let type. For example
list(x, y) where
y are of type
Generally this prevents clashes with other library names.
Lpp strives to provide the Common Lisp specified semantics and
wherever possible functions are named for their Common Lisp
counterparts and replacing dashes by capitalizing the first character
after the dash. For example the Common Lisp function
makeString. This was decided over
replacing dashes with underscores since such identifiers with capitals
would more likely be unique and, except for the prefix
allows a whole set of user defined identifiers with underscores that
can not possibly clash with Lpp identifiers. Other characters not
allowed in C++ identifiers are replaced by words, so
stringEqual. In some cases this does not work in which
case a reasonable alternative is chosen. For example
an identifier used in the C++ stream operations. So the identifier
listConcat was used instead of the Common Lisp specified
append. Another example is the Common Lisp specified
delete which is a reserved identifier in C++, so
is used as in "destructive remove".
In case 3 the Lpp macros reserve a small set of reserved identifiers. A mechanism is set up to redefine these per compilation unit by the programmer if a name clash happens to exist, See Redefining Predefined Names.
In case 4 all other reserved Lpp identifiers begin with
Lpp_ so the user should never define a name that begins with