Verified Commit 08bd31c0 authored by Bernd Paysan's avatar Bernd Paysan
Browse files

Help directory added

parent be87de01
<HEAD><TITLE>bigFORTH Documentation</TITLE></HEAD>
<H1>bigFORTH Documentation</H1>
<H2>Bernd Paysan <A HREF="">
<P><I>This manual describes bigFORTH and MINOS</I>
<H2><A NAME="toc1">1.</A> <A HREF="minos.html">MINOS</A></H2>
<H2><A NAME="toc2">2.</A> <A HREF="theseus.html">Theseus</A></H2>
<ADDRESS><hr size=5>
<A HREF="">Bernd Paysan</A>,
17may1998, 17may1998<BR>

515 Bytes

<HEAD><TITLE>Minos Documentation</TITLE></HEAD>
<IMG SRC="previous.jpg" ALT="Previous" Border=2>
<A HREF="minos-2.html"><IMG SRC="next.jpg" ALT="Next"></A>
<A HREF="minos.html#toc1"><IMG SRC="toc.jpg" ALT="Table of Contents"></A>
<H1><A NAME="s1">1. Introduction</H1>
<H2>What's MINOS?</H2>
<P>MINOS is the answer to the question ``Is there something like
Visual BASIC (Microsoft) or Delphi (Inprise) in Forth?'' - and the
answer is ``yes''.</P>
<P>Basically, these GUI RADs contain two components: a library with a
wide variety of elements for a graphical user interface; e.g. windows,
buttons, edit-controls, drawing areas, etc.; and an editor to combine
the elements with the mouse by drag&amp;drop or click&amp;point
actions. Missing code then is inserted to add actions when buttons are
<P>Typical applications are often related to data base
access. Therefore, many of these systems already contain a data base
engine or at least a standardized interface to a data base, such as
<P>Another aspect are complex components. With some of these toolkits,
you can create a web browser with some mouse clicks and a few
keystrokes. However, these components hide their details, a shrink
wrapped web browser application is not necessarily worse.</P>
<P>The interactivity of these tools usually is not very high. You
create your form, write your actions as code and compile it more
(Delphi) or less (Visual Age for C++) fast. Trying it usually isn't
possible before the compiler run.</P>
<H2>Why Visual?</H2>
<P>It isn't really necessary to brush graphical user interfaces
together, as it isn't to edit texts WYSIWYG. Many typesetting
functions are more semantically than visual, e.g. a text is a headline
or emphasized instead of written in bold 18 point Garamond or 11 point
Roman italics. All this is true for user interfaces, to some extend
much more. It's not the programmer that decides which font and size to
use for the UI - that's up to the user. As is color of buttons and
<P>Also to layout individual widgets, more abstraction than defining
position, width and height makes sense. Typically buttons are arranged
horizontally or vertically, perhaps with a bit distance between
them. The size of buttons must follow the containing strings, and
should conform to aesthetics (e.g. each button in a row has the same
<P>Such an abstract model, related to TeX's boxes&amp;glues, programs
quite good even without a visual editor. The programmer isn't
responsible for ``typesetting'' the buttons and boxes. This approach
is quite usual in Unix. Motif and Tcl/Tk use neighborhood relations,
Interviews uses boxes&amp;glues. I decided for boxes&amp;glues, since it's a
fast and intuitive solution, although it needs more objects to get the
same result.</P>
<P>These concepts contradict somehow with a graphical editing process,
since the editors I know don't provide abstract concepts (``place left
of an object'' or ``place in a row''), but positions.</P>
<H2>Visual Forth?</H2>
<P>One point makes me think: the packets that allow real visual form
programming have many years of programming invested in. Microsoft,
Borland, and IBM may hire hundreds of programmers just for one such
project. This man-power isn't available for any Forth project. But
<LI> Forth claims that good programmers can work much more
efficient with Forth
<LI> A team of 300 (wo)men blocks itself. If the boss partitions the
work, the programmers need to document functions, and to read
documents from other programmer related to other functions and must
understand them, or ask questions to figure things out. Everybody
knows that documenting takes much longer than writing the code, and
explaining is even worse. Thus at a certain project complexity level,
no time is left for the programming task; all time is used to specify
planned functions and read the specification from other
programmers. Or the programmers just chat before the door holes of the
much too small and noisy cubicles.
<LI> A good programmer reportedly works 20 times as fast as a bad,
even though he can't type in more key strokes per time. The resulting
program is either up to 20 times shorter or has 20 times less bugs (or
both) - with more functionality at the same time. Teamwork however
prevents good programmers from work, since they are frustrated by bad
programmers surrounding them, from their inability to produce required
information in time; and the bad programmers are frustrated by the
good ones, which makes them even worse.
<LI> Therefore, even in large projects, the real work is (or should
be) done by a small ``core team''. Then the Dilbert rule applies: what
can be done with two people, can be done with one at half of the
Furthermore, bigFORTH-DOS already contains a ``Text-GUI'', without
graphical editor, but with an abstract boxes&amp;glue concept, which, as
claimed above, hinders the use of such an editor.</P>
<P>Finally I wanted to get rid of DOS, and port bigFORTH to a real
operating system (Linux). In contrast to Windows and OS/2, user
interface and screen access are separated there. Drawing on the screen
uses the X Window System (short X), the actual user interface is
implemented in a library. This is the reason, why there is no common
interface, but a lot of different libraries, such as Athena Widgets,
Motif, Tcl/Tk, xforms, Qt, gtk, and others. The ``look and feel'' from
Motif-like buttons is quite common, even Windows and MacOS resemble
<P>All these libraries have disadvantages. The Athena Widgets are
hopelessly outdated. Motif is commercial, even if a free clone
(Lesstif) is in creation. It's slow and a memory hog. Tcl/Tk consumes
less memory, but it's <EM>even</EM> slower. How do you explain your
users that drawing a window takes seconds, while Quake renders
animated 3D-graphic on the same machine? Qt is fast, but it's written
in C++ and doesn't have a foreign language interface now. gtk, the
GIMP toolkit, has more foreign language interfaces, and it's free, but
it wasn't available until recently.</P>
<P>Therefore I decided to port the widget classes from bigFORTH-DOS
to X, and write an editor for it. Such classes written in Forth
naturally fit in an development environment and are - from the Forth
point of view - easier to maintain. There are not such many widget
libraries in C, because it's a task written in an afternoon, but
because the available didn't fit the requests, and a modification
looked desperate.</P>
<H2>The Name - Why MINOS?</H2>
<P>``Visual XXX'' is an all day's name, and it's too much of a
microsoftism for me. ``Forth'' is a no-word, especially since the
future market consists of one billion Chinese, and for them four is a
number of unluck (because ``se'' (four) sounds much like ``se''
(death)). However, even Borland doesn't call their system ``Visual
TurboPascal'', but ``Delphi''.</P>
<P>Greek is good, anyway, since this library relates to the
boxes&amp;glues model of TeX, which is pronounced Greek, too. Compared
with Motif, the library is quite copact (MINimal), and since it's
mainly for Linux, the phonetic distance is small... I pronounce it
Greek: ``meenoz''.</P>
<H2>Port to Windows</H2>
<P>I ported MINOS to Windows 95/NT, on the demand of some potential
users. It doesn't run near as stable as under Linux/X, since there are
a hideous number of subtle bugs in Windows, and I don't have the time
to work around all of them. Drawing polygons doesn't work as well as
on X, and all the bugs that are in the memory drawing device can drive
me nuts. The Windows port of MINOS looks more like the ``modern
Forth'' Claus Vogt portrayed in <A
HREF="news:de.comp.lang.forth">de.comp.lang.forth</A>: it shows random
general protection faults. Well, just like any other Windows
<IMG SRC="previous.jpg" ALT="Previous" Border=2>
<A HREF="minos-2.html"><IMG SRC="next.jpg" ALT="Next"></A>
<A HREF="minos.html#toc1"><IMG SRC="toc.jpg" ALT="Table of Contents"></A>
<ADDRESS><hr size=5>
<A HREF="">Bernd Paysan</A>,
09feb1999, 09feb1999<BR>
<HEAD><TITLE>Widget Classes</TITLE></HEAD>
<A HREF="minos-1.html"><IMG SRC="previous.jpg" ALT="Previous"></A>
<A HREF="minos-3.html"><IMG SRC="next.jpg" ALT="Next"></A>
<A HREF="minos.html#toc2"><IMG SRC="toc.jpg" ALT="Table of Contents"></A>
<H1><A NAME="s2">2. Widget Classes</A></H1>
<P>The primary classes of MINOS are gadgets (widgets and displays),
actors, and resources (xresource and font).</P>
<P>Resources just provide system-specific data like window handles,
display pointers, font informations, etc., they are critical for
system-specific parts of display implementations.</P>
<P>Widgets are the central objects represented on screen. Widgets draw
through displays, such as windows, viewports, etc. Since many displays
can be embedded into a bigger window, they also have all widget
functionality. Widgets are composed in boxes (horizontal and
vertical), and automatically layouted. Boxes certainly are widgets
themselves, and some of the more complicated widgets such as sliders
or textboxes are derived from boxes to layout the inner parts easily.</P>
<P>Actors are bound to associated actions when operating a widget
(i.e. clicking on it, pointing on it, or entering text). Actors
provide the way to script actions.</P>
<H2><A NAME="ss2.1">2.1 Actors</A></H2>
<DD><P>All Actors have the following methods in common:
<LI><B>called</B> This variable points to the object that is being called
<LI><B>caller</B> This variable points to the object that is
calling (the widget).
<LI><B>set</B> ( -- ) sets the flag
<LI><B>reset</B> ( -- ) resets the flag
<LI><B>toggle</B> ( -- ) toggles the flag
<LI><B>fetch</B> ( -- x1 .. xn ) queries the value(s)
<LI><B>store</B> ( x1 .. xn -- ) changes the value(s)
<LI><B>click</B> ( x y b n -- ) performs the action for a click
<LI><B>key</B> ( key sh -- ) performs the action for a keystroke
<LI><B>enter</B> ( -- ) performs the action for entering the widget
<LI><B>leave</B> ( -- ) performs the action for leaving the widget
<LI><B>assign</B> ( x1 .. xn -- ) initially assigns the state
<LI><B>set-called</B> ( o -- ) sets the called object
The stack effect you see below is the stack effect of the init method.</P>
<DD><DL><DT><B>KEY-ACTOR</B> This is an actor for keyboard macros. It
inserts keystrokes into the called widget.
<DT><B>TOOLTIP</B> ( actor tip -- ) A tooltip is a nested actor; it shows
the widget tip some time after entering with the mouse, and forwards the other
messages to actor
<DT><B>EDIT-ACTION</B> ( o xt -- ) This actor handles text input field key
events, and does all the editing stuff. After each keystroke and each click,
it calls xt ( -- ).
<DD><DL><DT><B>NUMBER-ACTION</B> ( o xt -- ) Same as EDIT-ACTION, but filters
out digits only
</DL></DL><DD><DL><DT><B>SCALE-VAR</B> ( o pos max -- ) Scaler actor,
keeps position and maximum value in own variables.
<DD><DL><DT><B>SCALE-DO</B> ( o pos max xt -- ) Same as SCALE-VAR, but executes
xt ( pos -- ) on changes
<DT><B>SLIDER-VAR</B> ( o pos max step -- ) Slider actor, keeps position,
step, and maximum value in own variables
<DD><DL><DT><B>SLIDER-DO</B> ( o pos max step xt -- ) Same as SLIDER-VAR,
but executes xt ( -- ) on changes
</DL></DL><DT><B>SIMPLE</B> ( o xt -- ) xt is executed at every store (no
state maintained)
<DD><DL><DT><B>DRAG</B> ( o xt -- ) Calls toggle on each click event
<DT><B>REP</B> ( o xt -- ) Calls toggle repeatedly while the user holds down
the mouse button
</DL><DT><B>TOGGLE-STATE</B> ( o xtstore xtfetch -- ) allows generic fetch
and store functions
<DD><DL><DT><B>SCALE-ACT</B> ( o do-store do-fetch max -- ) Generic slider
actor (maximum slider position provided)
<DD><DL><DT><B>SLIDER-ACT</B> ( o do-store do-fetch max -- ) Generic scaler
actor (maximum scaler position provided)
</DL></DL><DT><B>TOGGLE-VAR</B> ( o addr xt -- ) keeps the flag in addr,
and executes xt on changes
<DD><B>TOGGLE-NUM</B> ( o n addr xt -- ) is responsible for state n in addr
(sets addr to n when set), and executes xt on changes
<DT><B>TOGGLE</B> ( o state xtset xtreset -- ) models a flag with
initial state and two functions for each state
<H2><A NAME="ss2.2">2.2 Resources</A></H2>
<H2><A NAME="ss2.3">2.3 Widgets</A></H2>
<H2><A NAME="ss2.4">2.4 Boxes</A></H2>
COMBINED 44 E4 40139938
VBOX 44 E4 4013B15C
SLIDERVIEW 4C E8 40146360
VSLIDER 44 E8 401423B4
VSCALER 50 EC 401434F4
VSLIDER0 44 E8 40142B74
VRBOX 44 E4 40140E74
VTBOX 44 E4 4013C59C
VRTBOX 44 E4 4014163C
VATBOX 44 E4 4013CB70
VARTBOX 44 E4 40141760
VASBOX 4C E8 40147340
VRESIZE 44 E4 40146FF0
MODAL 48 E4 401418AC
VARBOX 44 E4 40141058
HBOX 44 E4 4013A84C
INFO-MENU 54 E4 4014CA70
HSLIDER 44 E8 40141D94
HSCALER 50 EC 40142E98
HSLIDER0 44 E8 4014292C
HRBOX 44 E4 401411B8
HTBOX 44 E4 4013C0E8
HRTBOX 44 E4 401413F8
HATBOX 44 E4 4013CA50
HARTBOX 44 E4 4014151C
HABOX 44 E4 4013BFC8
HASBOX 4C E8 40147558
HRESIZE 44 E4 40147138
HARBOX 44 E4 401412D8
TEXTFIELD 48 E4 40140A08
(NIL 24 C8 40137B80
GLUE 34 C8 401379F8
GLCANVAS 58 CC 4014B670
RULE 38 C8 40138458
CANVAS 78 118 40138FCC
MFILL 38 C8 40138A48
MSKIP 38 C8 40138908
SSKIP 40 C8 40146178
VRULE 38 C8 40138734
HRULE 38 C8 40138618
VGLUE 34 C8 40138308
HGLUE 34 C8 401381EC
TOPGLUE 34 C8 4013E908
ICON 28 C8 401377E4
<H2><A NAME="ss2.5">2.5 Displays</A></H2>
DISPLAYS 90 178 4012FC60
WINDOW A4 194 40148B18
MENU-WINDOW A4 194 4014D09C
FRAME A8 1A4 4014A698
MENU-FRAME A8 1A4 4014C0D0
WINDOW-STUB A4 194 4014A2C0
(NILSCREEN 90 178 40137D00
BACKING A8 17C 40131DD0
VIEWPORT E0 190 40143EB4
SCRVIEWPORT E0 190 40123590
HVIEWPORT E8 190 40145F14
VVIEWPORT E8 190 40145CC4
BEAMER B8 180 401330F8
<A HREF="minos-1.html"><IMG SRC="previous.jpg" ALT="Previous"></A>
<A HREF="minos-3.html"><IMG SRC="next.jpg" ALT="Next"></A>
<A HREF="minos.html#toc2"><IMG SRC="toc.jpg" ALT="Table of Contents"></A>
<ADDRESS><hr size=5>
<A HREF="">Bernd Paysan</A>,
09feb1999, 21jul1999<BR>
\ No newline at end of file
<HEAD><TITLE>Support Classes</TITLE></HEAD>
<A HREF="minos-2.html"><IMG SRC="previous.jpg" ALT="Previous"></A>
<IMG SRC="next.jpg" ALT="Next" Border=2>
<A HREF="minos.html#toc3"><IMG SRC="toc.jpg" ALT="Table of Contents"></A>
<H1><A NAME="s2">3. Support Classes</A></H1>
<H2><A NAME="ss3.1">3.1 3D Turtle Graphics - ``Dragon Graphics''</A></H2>
<P>To support OpenGL drawing and make it much easier than plain
OpenGL, there is a 3D turtle graphics, also called ``dragon
graphics''. The basic principle of turtle graphics is the ``turtle'',
a directed point in the coordinate space that can move around and
leaves a trail on its way.</P>
<P>For 2D turtle graphics, there are not much settings to choose. You
can set the color and the width of the line you stroke, or choose to
fill your path, but that's it. 3D objects have much more aspects than
simple lines or flat surfaces. Therefore, a 3D turtle graphics demands
other features to define the trail it leaves.</P>
<P>First, the turtle flies through space, and is therefore called
``dragon''. This increases the degree of freedom - a 2D turtle can
only turn left or right, a 3D dragon can turn left, right, up, and
down. Additionally, it can roll to the left or right.</P>
<P>Then you have to define the vertex points of your trail yourself. You
can define points around the current position of the dragon, which are
connected to points around the previous stop of the dragon. These
rounds around the dragon are knit together, forming the ``trail'' of
the dragon. You can add or drop vertex points, but if you drop point,
make sure that they are at least on a straight line (or better all on
the same location).</P>
<P>There are several groups of operation, let's start with the
navigation of the dragon. The angles used are radians by default.
<LI><B>left</B> ( f -- ) turns the dragon's head left
<LI><B>right</B> ( f -- ) turns the dragon's head right
<LI><B>up</B> ( f -- ) turns the dragon's head up
<LI><B>down</B> ( f -- ) turns the dragon's head down
<LI><B>roll-left</B> ( f -- ) rolls the dragon's head left
<LI><B>roll-right</B> ( f -- ) rolls the dragon's head right
<LI><B>x-left</B> ( f -- ) rotate the dragon left around the x axis
<LI><B>x-right</B> ( f -- ) rotate the dragon right around the x axis
<LI><B>y-left</B> ( f -- ) rotate the dragon left around the y axis
<LI><B>y-right</B> ( f -- ) rotate the dragon right around the y axis
<LI><B>z-left</B> ( f -- ) rotate the dragon left around the z axis
<LI><B>z-right</B> ( f -- ) rotate the dragon right around the z axis
<LI><B>forward</B> ( f -- ) move the dragon in z direction
<LI><B>forward-xyz</B> ( fx fy fz -- ) move the dragon
<LI><B>degrees</B> ( f -- ) steps per circle. Common cases: 2pi for
radians, 360 for deg, 64 for asian degrees, or whatever you find
suits your application best.
<LI><B>scale</B> ( f -- ) scales the dragon's step width by the factor f
<LI><B>scale-xyz</B> ( fx fy fz -- ) scale the dragon's step width in
x, y, and z direction
<LI><B>flip-clock</B> ( -- ) change default coordinate from left hand
to right or the other way round. Use that after scale-xyz with an odd
number of negative scale factors.
<P>There are some functions to save and restore the turtle's state,
and to use the turtle matrix stack for matrix multiplications, so that
you can create arbitrary synthetic transformations with one step.
<LI><B>&gt;matrix</B> ( -- ) push turtle matrix on the matrix stack
<LI><B>matrix&gt;</B> ( -- ) pop turtle matrix from the matrix stack
<LI><B>matrix@</B> ( -- ) copy turtle matrix from the stack
<LI><B>1matrix</B> ( -- ) initialize turtle state with the identity matrix
<LI><B>matrix*</B> ( -- ) multiply current transformation matrix with
the one on the top of the matrix stack (and pop that one)
<LI><B>clone</B> ( -- o ) create a clone of the turtle
<LI><B>&gt;turtle</B> ( -- ) clone the turtle and use it as current object
<LI><B>turtle&gt;</B> ( -- ) destroy current turtle and pop previos
<P>Then there are the operations to create pathes. A path is
partitioned in ``rounds'', where each point in one round is connected
to the corresponding point in the previous round. Rounds can add
points or drop points from the previous round (dropped points are not
connected, and therefore should be at least in a line with those
points that are connected). The first round in a path has to be
defined immediately after open-path, the other rounds must be enclosed
in open-round and close-round.
<LI><B>open-path</B> ( n -- ) opens a path with n points in the first
<LI><B>close-path</B> ( -- ) closes a path and performs the final
rendering action
<LI><B>next-round</B> ( -- ) closes a round and opens the next one
<LI><B>open-round</B> ( n -- ) opens a round with n points (obsolete)
<LI><B>close-round</B> ( -- ) closes a round (by copying the first
point as last point) and performs the per-round rendering action (obsolete)
<LI><B>finish-round</B> ( -- ) performs the per-round rendering
action without closing the round first (this is for open objects) (obsolete)
<LI><B>add-xyz</B> ( fx fy fz -- ) adds the point at the
x,y,z-coordinates relative to the turtle. x is up from the turtle, y
right, z before. The point is connected to the same point of the
previous round as the point before.
<LI><B>set-xyz</B> ( fx fy fz -- ) sets a point with
x,y,z-coordinates. The point is connected to the next point of the
previous round as the point before.
<LI><B>drop-point</B> ( -- ) skips one point, set-xyz is equal to
add-xyz drop-point
<LI><B>set-rpz</B> ( fr fphi fz -- ) set with cylinder coordinates
<LI><B>set-xy</B> ( fx fy -- ) set-xyz with z=0
<LI><B>set-rp</B> ( fr fphi -- ) set with cylinder coordinates, z=0
<LI><B>set-r</B> ( fr -- ) set with cylinder coordinates, z=0,
phi=current_phi, current_phi+=dphi
<LI><B>set</B> ( -- ) set at current dragon location
<LI><B>add-rpz</B> ( fr fphi fz -- ) add with cylinder coordinates
<LI><B>add-xy</B> ( fx fy -- ) add-xyz with z=0
<LI><B>add-rp</B> ( fr fphi -- ) add with cylinder coordinates, z=0
<LI><B>add-r</B> ( fr -- ) add with cylinder coordinates, z=0,
phi=current_phi, current_phi+=dphi
<LI><B>add</B> ( -- ) add at current dragon location
<LI><B>set-dphi</B> ( fdphi -- ) sets dphi
<P>The turtle graphics supports several drawing modes: points,
wire-frame, solid, and textured.
<LI><B>points</B> ( -- ) draw only vertex points
<LI><B>lines</B> ( -- ) draw a wire frame
<LI><B>triangles</B> ( -- ) draw solid triangles
<LI><B>textured</B> ( -- ) draw textured triangles
<LI><B>smooth</B> ( -- ) variable: set on for smooth normals when
rendering textured, set off for non-smooth rendering
<LI><B>xy-texture</B> ( -- ) texture mapping based on x and y
<LI><B>zphi-texture</B> ( -- ) texture mapping based on z and phi
<LI><B>rphi-texture</B> ( -- ) texture mapping based on r and phi
<LI><B>zp-texture</B> ( -- ) texture mapping based on z and the point
number coordinates
<LI><B>load-texture</B> ( addr u -- t ) loads a ppm file with the
name <B>addr u</B> and returns the texture index <B>t</B>
<LI><B>set-light</B> ( par1..4 par n -- ) Set light source n
<H2><A NAME="ss3.2">3.2 SQL Interface</A></H2>
<P>The SQL interface allows to interface with a database using the
structured query language SQL. It now has only an interface to
PostgreSQL, because noone wrote one to other databases.</P>
<P>The database interface has a simple foundation. You can send an SQL
query string and get the result back as a table.
<LI><B>database new</B> ( addr u -- ) opens the database specified by
<LI><B>exec</B> ( addr u -- ) the query string
<LI><B>fields</B> ( -- n ) the number of fields per result
<LI><B>tuples</B> ( -- n ) the number of tuples (results)
<LI><B>field@</B> ( i -- addr u ) obtains the field name
<LI><B>tuple@</B> ( i j -- addr u ) obtains a tuple entry
<LI><B>clear</B> ( -- ) clears the result buffer
<P>There are also some output functions to display the result of a
query or to create a table containing the entries
<LI><B>.heads</B> ( -- ) displays the field names
<LI><B>.entry</B> ( i -- ) displays an entry line
<LI><B>.entries</B> ( -- ) displays all results including names
<LI><B>entry-box</B> ( -- o ) creates a MINOS object with the query results
<P>A set of methods facilitates the creations of new tables
<LI><B>create(</B> ( addr u -- ) starts creation of a named table
<LI><B>:string</B> ( addr u n -- ) a <TT>varchar</TT> array with n
chars max
<LI><B>:int</B> ( addr u -- ) an integer
<LI><B>:float</B> ( addr u -- ) a floating point number
<LI><B>:date</B> ( addr u -- ) a date
<LI><B>:time</B> ( addr u -- ) a time
<LI><B>inherits</B> ( addr u -- ) inherit mechanism of PostgreSQL,
must be last (there may be multiple inherits statements)
<LI><B>)</B> ( -- ) ends the creation o a table
<LI><B>drop</B> ( addr u -- ) drops a table
<P>There are also ways to construct a query string
<LI><B>select</B> ( addr u -- ) starts a select query, the argument is
the selection; there can be several selections per query
<LI><B>select-distinct</B> ( addr u -- ) starts a select distinct
<LI><B>select-as</B> ( addr1 u1 addr2 u2 -- ) argument 1 is the
selection, argument 2 is the name it is assigned to