ref.html

A very small LISP implementation with several packages and demo programs.

are available in <code>@@@</code>, <code>@@</code> and <code>@</code>, in that
order (i.e the latest result is in <code>@</code>).

<p><pre><code>
: (+ 1 2 3)
-> 6
: (/ 128 4)
-> 32
: (- @ @@)        # Subtract the last two results
-> 26
</code></pre>

<p><dt>Flow functions
<dd>Flow- and logic-functions store the result of their controlling expression -
respectively non-<code>NIL</code> results of their conditional expression - in
<code>@</code>.

<p><pre><code>
: (while (read) (println 'got: @))
abc            # User input
got: abc       # print result
123            # User input
got: 123       # print result
NIL
-> 123

: (setq L (1 2 3 4 5 1 2 3 4 5))
-> (1 2 3 4 5 1 2 3 4 5)
: (and (member 3 L) (member 3 (cdr @)) (set @ 999))
-> 999
: L
-> (1 2 3 4 5 1 2 999 4 5)
</code></pre>

<p>Functions with controlling expressions are
   <a href="refC.html#case">case</a>,
   <a href="refP.html#prog1">prog1</a>,
   <a href="refP.html#prog2">prog2</a>,
and the bodies of <code><a href="refR.html#*Run">*Run</a></code> tasks.

<p>Functions with conditional expressions are
   <a href="refA.html#and">and</a>,
   <a href="refC.html#cond">cond</a>,
   <a href="refD.html#do">do</a>,
   <a href="refF.html#for">for</a>,
   <a href="refI.html#if">if</a>,
   <a href="refI.html#if2">if2</a>,
   <a href="refI.html#ifn">ifn</a>,
   <a href="refL.html#loop">loop</a>,
   <a href="refN.html#nand">nand</a>,
   <a href="refN.html#nond">nond</a>,
   <a href="refN.html#nor">nor</a>,
   <a href="refO.html#or">or</a>,
   <a href="refS.html#state">state</a>,
   <a href="refU.html#unless">unless</a>,
   <a href="refU.html#until">until</a>,
   <a href="refW.html#when">when</a> and
   <a href="refW.html#while">while</a>.

</dl>

<p><code>@</code> is generally local to functions and methods, its value is
automatically saved upon function entry and restored at exit.


<p><hr>
<h3><a name="cmp">Comparing</a></h3>

<p>In Pico Lisp, it is legal to compare data items of arbitrary type. Any two
items are either

<p><dl>

<dt>Identical
<dd>They are the same memory object (pointer equality). For example, two
internal symbols with the same name are identical.

<dt>Equal
<dd>They are equal in every respect (structure equality), but need not to be
identical. Examples are numbers with the same value, transient symbols with the
same name or lists with equal elements.

<dt>Or they have a well-defined ordinal relationship
<dd>Numbers are comparable by their numeric value, strings by their name, and
lists recursively by their elements (if the CAR's are equal, their CDR's are
compared). For differing types, the following rule applies: Numbers are less
than symbols, and symbols are less than lists. As special cases,
<code>NIL</code> is always less than anything else, and <code>T</code> is always
greater than anything else.

</dl>

<p>To demonstrate this, <code><a href="refS.html#sort">sort</a></code> a list of
mixed data types:

<p><pre><code>
: (sort '("abc" T (d e f) NIL 123 DEF))
-> (NIL 123 DEF "abc" (d e f) T)
</code></pre>

<p>See also <code><a href="refM.html#max">max</a></code>, <code><a
href="refM.html#min">min</a></code>, <code><a
href="refR.html#rank">rank</a></code>, <code><a href="ref_.html#<"><</a></code>,
<code><a href="ref_.html#=">=</a></code>, <code><a
href="ref_.html#>">></a></code> etc.


<p><hr>
<h3><a name="oop">OO Concepts</a></h3>

<p>Pico Lisp comes with built-in object oriented extensions. There seems to be a
common agreement upon three criteria for object orientation:

<p><dl>
<dt>Encapsulation
<dd>Code and data are encapsulated into <u>objects</u>, giving them both a
<u>behavior</u> and a <u>state</u>. Objects communicate by sending and receiving
<u>messages</u>.

<dt>Inheritance
<dd>Objects are organized into <u>classes</u>. The behavior of an object is
inherited from its class(es) and superclass(es).

<dt>Polymorphism
<dd>Objects of different classes may behave differently in response to the same
message. For that, classes may define different methods for each message.

</dl>

<p>Pico Lisp implements both objects and classes with symbols. Object-local data
are stored in the symbol's property list, while the code (methods) and links to
the superclasses are stored in the symbol's VAL (encapsulation).

<p>In fact, there is no formal difference between objects and classes (except
that objects usually are anonymous symbols containing mostly local data, while
classes are named internal symbols with an emphasis on method definitions). At
any time, a class may be assigned its own local data (class variables), and any
object can receive individual method definitions in addition to (or overriding)
those inherited from its (super)classes.

<p>Pico Lisp supports multiple inheritance. The VAL of each object is a
(possibly empty) association list of message symbols and method bodies,
concatenated with a list of classes. When a message is sent to an object, it is
searched in the object's own method list, and then (with a left-to-right
depth-first search) in the tree of its classes and superclasses. The first
method found is executed and the search stops. The search may be explicitly
continued with the <code><a href="refE.html#extra">extra</a></code> and <code><a
href="refS.html#super">super</a></code> functions.

<p>Thus, which method is actually executed when a message is sent to an object
depends on the classes that the object is currently linked to (polymorphism). As
the method search is fully dynamic (late binding), an object's type (i.e. its
classes and method definitions) can be changed even at runtime!

<p>While a method body is being executed, the global variable <code><a
href="refT.html#This">This</a></code> is set to the current object, allowing
the use of the short-cut property functions <code><a
href="ref_.html#=:">=:</a></code>, <code><a href="ref_.html#:">:</a></code>
and <code><a href="ref_.html#::">::</a></code>.


<p><hr>
<h3><a name="dbase">Database</a></h3>

<p>On the lowest level, a Pico Lisp database is simply a collection of <a
href="#external">external symbols</a>. They reside in a database file, and are
dynamically swapped in and out of memory. Only one database can be open at a
time (<code><a href="refP.html#pool">pool</a></code>).

<p>The symbols in the database can be used to store arbitrary information
structures. In typical use, some symbols represent nodes of search trees, by
holding keys, values, and links to subtrees in their VAL's. Such a search tree
in the database is called <u>index</u>.

<p>For the most part, other symbols in the database are objects derived from the
<code>+Entity</code> class.

<p>Entities depend on objects of the <code>+Relation</code> class hierarchy.
Relation-objects manage the property values of entities, they define the
application database model and are responsible for the integrity of mutual
object references and index trees.

<p>Relations are stored as properties in the entity classes, their methods are
invoked as daemons whenever property values in an entity are changed. When
defining an <code>+Entity</code> class, relations are defined - in addition to
the method definitions of a normal class - with the <code><a
href="refR.html#rel">rel</a></code> function. Predefined relation classes
include

<p><ul>
<li>Primitive types like
   <dl>
   <dt><code>+Symbol</code>
   <dd>Symbolic data
   <dt><code>+String</code>
   <dd>Strings (just a general case of symbols)
   <dt><code>+Number</code>
   <dd>Integers and fixed-point numbers
   <dt><code>+Date</code>
   <dd>Calendar date values, represented by a number
   <dt><code>+Time</code>
   <dd>Time-of-the-day values, represented by a number
   <dt><code>+Blob</code>
   <dd>"Binary large objects" stored in separate files
   </dl>
<li>Object-to-object relations
   <dl>
   <dt><code>+Link</code>
   <dd>A reference to some other entity
   <dt><code>+Hook</code>
   <dd>A reference to an entity holding object-local index trees
   <dt><code>+Joint</code>
   <dd>A bi-directional reference to some other entity
   </dl>
<li>Container prefix classes like
   <dl>
   <dt><code>+List</code>
   <dd>A list of any of the other primitive or object relation types
   <dt><code>+Bag</code>
   <dd>A list containing a mixture of any of the other types
   </dl>
<li>Index prefix classes
   <dl>
   <dt><code>+Ref</code>
   <dd>An index with other primitives or entities as key
   <dt><code>+Key</code>
   <dd>A unique index with other primitives or entities as key
   <dt><code>+Idx</code>
   <dd>A full-text index, typically for strings
   <dt><code>+Sn</code>
   <dd>Tolerant index, using the Soundex-Algorithm
   </dl>
<li>Booleans
   <dl>
   <dt><code>+Bool</code>
   <dd><code>T</code> or <code>NIL</code>
   </dl>
<li>And a catch-all class
   <dl>
   <dt><code>+Any</code>
   <dd>Not specified, may be any of the above relations
   </dl>
</ul>


<p><hr>
<h3><a name="pilog">Pilog (Pico Lisp Prolog)</a></h3>

<p>A declarative language is built on top of Pico Lisp, that has the semantics
of Prolog, but uses the syntax of Lisp.

<p>For an explanation of Prolog's declarative programming style, an introduction
like "Programming in Prolog" by Clocksin/Mellish (Springer-Verlag 1981) is
recommended.

<p>Facts and rules can be declared with the <code><a
href="refB.html#be">be</a></code> function. For example, a Prolog fact
'<code>likes(john,mary).</code>' is written in Pilog as:

<p><pre><code>
(be likes (John Mary))
</code></pre>

<p>and a rule '<code>likes(john,X) :- likes(X,wine), likes(X,food).</code>' is
in Pilog:

<p><pre><code>
(be likes (John @X) (likes @X wine) (likes @X food))
</code></pre>

<p>As in Prolog, the difference between facts and rules is that the latter ones
have conditions, and usually contain variables.

<p>A variable in Pilog is any symbol starting with an at-mark character
("<code>@</code>"). The symbol <code>@</code> itself can be used as an anonymous
variable: It will match during unification, but will not be bound to the matched
values.

<p>The <i>cut</i> operator of Prolog (usually written as an exclamation mark
(<code>!</code>)) is the symbol <code>T</code> in Pilog.

<p>Pilog can be called from Lisp and vice versa:

<ul>

<li>The interface from Lisp is via the functions <code><a
href="refG.html#goal">goal</a></code> (prepare a query from Lisp data) and
<code><a href="refP.html#prove">prove</a></code> (return an association list of
successful bindings).

<li>When the CAR of a Pilog clause is a Pilog variable, the CDR is executed as a
Lisp expression and the result unified with that variable.

<li>Within such a Lisp expression in a Pilog clause, the current bindings of
Pilog variables can be accessed with the <code><a
href="ref_.html#->">-&gt</a></code> function.

</ul>

<p>An interactive query can be done with the <code><a
href="ref_.html#?">?</a></code> function:

<p><pre><code>
(? (likes John @X))
</code></pre>

<p>This will print all solutions, waiting for user input after each line. If a
non-empty line (not just a ENTER key, but for example a dot (<code>.</code>)
followed by ENTER) is typed, it will terminate.


<p><hr>
<h3><a name="conv">Naming Conventions</a></h3>

<p>It was necessary to introduce - and adhere to - a set of conventions for Pico
Lisp symbol names. Because all (internal) symbols have a global scope (there are
no packages or name spaces), and each symbol can only have either a value or
function definition, it would otherwise be very easy to introduce name
conflicts. Besides this, source code readability is increased when the scope
of a symbol is indicated by its name.

<p>These conventions are not hard-coded into the language, but should be so into
the head of the programmer. Here are the most commonly used ones:

<p><ul>
<li>Global variables start with an asterisk "<code>*</code>"
<li>Functions and other global symbols start with a lower case letter
<li>Locally bound symbols start with an upper case letter
<li>Local functions start with an underscore "<code>_</code>"
<li>Classes start with a plus-sign "<code>+</code>"
<li>Methods end with a right arrow "<code>></code>"
</ul>

<p>For historical reasons, the global constant symbols <code>T</code> and
<code>NIL</code> do not obey these rules, and are written in upper case.

<p>For example, a local variable could easily overshadow a function definition:

<p><pre><code>
: (de max-speed (car)
   (.. (get car 'speeds) ..) )
-> max-speed
</code></pre>

<p>Inside the body of <code>max-speed</code> (and all other functions called
during that execution) the kernel function <code>car</code> is redefined to some
other value, and will surely crash if something like <code>(car Lst)</code> is
executed. Instead, it is safe to write:

<p><pre><code>
: (de max-speed (Car)            # 'Car' with upper case first letter
   (.. (get Car 'speeds) ..) )
-> max-speed
</code></pre>

<p>Note that there are also some strict naming rules (as opposed to the
voluntary conventions) that are required by the corresponding kernel
functionalities, like:

<p><ul>
<li>Transient symbols are enclosed in double quotes (see <a
href="#transient-io">Transient Symbols</a>) <li>External symbols are enclosed in
braces (see <a href="#external-io">External Symbols</a>) <li>Pattern-Wildcards
start with an at-mark "<code>@</code>" (see <a href="refM.html#match">match</a>
and <a href="refF.html#fill">fill</a>) <li>Symbols referring to a shared library
contain a colon "<code>lib:sym</code>" </ul>

<p>With that, the last of the above conventions (local functions start with an
underscore) is not really necessary, because true local scope can be enforced
with transient symbols.


<p><hr>
<h3><a name="trad">Breaking Traditions</a></h3>