COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	This file is a very brief introduction to LEAP.
C00005 00003	A association(relation instance) is inserted into the associative
C00008 00004	There are booleans and searches on sets of the form
C00013 ENDMK
C⊗;
This file is a very brief introduction to LEAP.

Leap essentially consists of associations (a single ternary relation
between items), sets (of items), and lists (sequences of items).

An item is essentially a SAIL variable which is declared to be available
for membership in associations, sets, and lists. It may have any standard
data-type (e.g be an integer array, a scalar set variable, a string variable
etc.) Items are obtained in two ways:

	1). By declaration.
		INTEGER ITEM INT1;
		STRING ARRAY ITEM SARR[1:10];
		SET ITEM SETITM;

	2) By execution of the (heap) allocator NEW which takes as its
	   argument an expression which will determine the shape, data-type
	   and initial value of the item.

	   E.G.
		NEW(1)
	   causes allocation of a new item with integer datum initialized 
	   to the value 1;

	   Items are returned to the heap via the DELETE (item) statement.

NOTE: if we are not going to use the arithmetic properties of an item, but
just the item's name we may declare the ITEM to be without data-type, or
create the item by calling NEW with no arguments.

We may store references (pointers) to items in special variables called
ITEMVARS. We declare the itemvar to either have a data-type such as

	 	INTEGER ITEMVAR PTRINT;

in which case we "promise" the compiler that we will only store references
to items which have a scalar integer datum. Itemvars are coerced into their
item values in the same way arithmetic values are.
	E.G.
		PTRINT ← INT1;
		PTRINT2 ← PTRINT;

is exactly equivalent to

		PTRINT ← INT1;
		PTRINT2 ← INT1;

To refer to the arithmetic value of an item we must use the DATUM operator.
There is never any hidden coercion between an item and its arithmetic datum
thus, whenever we wish to refer to the datum we must use the DATUM operator.

E. G.
	DATUM(INT1)←DATUM(INT1) +1;

A association(relation instance) is inserted into the associative
store (data base) via a make statement.

	MAKE A⊗O≡V; 

where A,O,V evaluate to items.

The association is removed from the associative store via an erase statement;

	ERASE A⊗O≡V;

It is common practice to refer to the three components of an association via
the terms ATTRIBUTE, OBJECT, and VALUE, and we do so in the following.


A set is made via mentioning all its elements.

E.G. 
	SETVAR ← { INT1, INT2 , INT3};

forms a set of three items and stores the set in the variable SETVAR.
Operations on sets include intersection,union, subtraction, finding
the number of elements in a set (LENGTH), comparison between sets for
equality, proper containment, and containment.

A list is also made via mentioning all its elements.

E.G.
	LISTVAR ← {{ INT1, INT2, INT1, INT3}}

The members of the list may be refered to by index

	E.G. LISTVAR[2] = INT2

Operations on lists include, concatenation, replacement of individual list
elements. Insertion of individual items in a specific place in the list, 
sublists, computing the length of a list, comparison for equality.

E.G
	LISTVAR[2] ← INT1;
	REMOVE 1 FROM LISTVAR;
	PUT INT4 IN LISTVAR AFTER 2;

now LISTVAR = {{INT1, INT1, INT4, INT3}}

There are booleans and searches on sets of the form

	X ε SETEXPR  or  Y ε LISTEXPR

Normally the above are booleans and return the values true
or false depending on whether the item X and Y are elements of
the corresponding SET or LIST expressions.

However we may also iterate a statement over the items contained within 
a set or list, via use of the FOREACH statement.


FOREACH PTRINT SUCH_THAT PTRINT ε INTSET DO
	DATUM(PTRINT) ← DATUM(PTRINT)+1;

Here PTRINT is an INTEGER ITEMVAR which is said to be a "local" of the
FOREACH.

The datum of each item in INTSET is incremented by one.

NOTE: that as sets are unordered there is no promise as to which order
the elements will be placed into PTRINT, but there is the promise that
each will be placed into PTRINT only once, and unless the FOREACH statement
is abnormally terminated (via a GO TO or RETURN) each element of the
set will at sometime be in PTRINT.

As lists are ordered, we do have explicit control. In fact in the above
if we had done the search over a list and the list contained the same
item twice, the datum of that item would be incremented twice.

We may use the boolean A⊗O≡V to determine whether the relation
instance A⊗O≡V is currently in the associative store.

We may search the associative store via a foreach also

FOREACH PTRFRUIT | COLOR ⊗ PTRFRUIT ≡ RED DO <statement>

would iterate the statement  with PTRFRUIT successively obtaining the
object component of each association in the associative store which
had its attribute component equal to color and its value component 
equal to  RED.

We may also have two components "unbound"

FOREACH PTRCOL, PTRFRUIT | COLOR ⊗ PTRFRUIT ≡ PTRCOL DO <statement>

in which case the statement will be executed once foreach pair of fruit,
color, such that COLOR⊗fruit≡color is in the associative store.

There is a special item called ANY which may be used in associative searches
or ERASE statements to match anything.

Thus 
		ERASE  COLOR⊗ANY≡ANY;

is equivalent to

to the above FOREACH where the <statement> is ERASE COLOR⊗PTRFRUIT≡PTRCOL;


We have another technique for searching the associative store, which is
highly valuable when we know that only a single relation instance will
satisfy our search. This is the binding boolean.

For example if we knew that their was a single fruit whose color was red
we might use the statement.

	IF COLOR⊗BIND PTRFRUIT≡ RED THEN <statement>.

This is useful in avoiding the very expensive coroutine mechanism used
via the FOREACH. The BIND may prefix any two itemvar arguments to the 
boolean.