LBPP Architecture Overview
--------------------------

Symbols

A symbol is variable, constant, function name, array name, keyword, or series
of alpha numeric characters.

Variable

A variable is a symbol.  A symbol is not a variable.  A variable includes an
array index.

Numeric Expression

A numeric expression is a series of numeric variables, numeric functions,
and constants seperated by numeric operators that can be nested in sets of
parathensises.

String Expression

A string expression is a series of string literals and string variables
seperated by the plus operator.

Statements

A statement is a series of alpha numeric characters followed by a series of
string expressions, numeric expressions, keywords, alpha numeric deliminators,
handles, and variables passed as an lvalue (by reference).

Special Statements

The following statements are translated internally due to the fact that they
modify the code around them.

FOR

NEXT

IF THEN

IF THEN ELSE

ELSE

ENDIF

GOTO

GOSUB

RETURN

Labels

A label is a symbol enclosed in brackets.  A label represents a position 
within the code.  In Liberty Basic, a label can be represented dynamically at
run time via the label name in a string form.  There is currently, no way to
directly this label as a string in Liberty Basic but support functions can
longjmp to the associated jmp_buf.

Functions

A function is a variable name followed by a parameter list.

Strings

Liberty Basic strings do not correspond with char *'s.  The are actually
structures that store the size of the string along with a pointer to the
memory occupied by the string.  There is an initial version of string
reference counting now in LBPP.  More work can be done to improve the
efficency of strings but that can be done in the future.  Some more pressing
issues need to be addressed first.

OPEN/PRINT/INPUT/CLOSE

The OPEN command is a great way to open up a generic object that can be read
to and written to.  It reminds me of the Unix file concept and is an amazing
way to handle things.  I want to approach the handle IO statements in a manner
similiar to Unix files.  Heres a brief explanation of how I think these
statements should translate from a libLB perspective:

OPEN "test" FOR input AS #test

Lookup handler for type 'input' and call the open method storing the results in
variable named '#test'

Handler for type 'input' would take the string parameter passed to it and try
to fopen() the corresponding filename with read access bringing up a notice
dialog and exiting if results == NULL.

PRINT #test, "test"

Same as above but end up calling fwrite.

CLOSE #test

Would boil down to a fclose call.

OPEN "Window" for window as #win
Lookup handler for type 'window' and call the open method storing results in
variable named '#win'

Handler for type 'window' would create a GTK window and return the object's
pointer as a result.

PRINT #win, "!trapclose [exit]"
Register an exit callback for the Window and associate the jmp_buf referenced
by [exit] with it.  When that callback is invoked, GOTO the [exit] if the
callback does not expect to be returned from.  If it does, we need to push the
current label onto the stack and expect LB to return from it.

INPUT #win, A$
Enter the AppMain loop for the Window.

[exit]
CLOSE #win
Destroy the window.  Much different from merely closing on most platforms...


I really think the ability to GOTO and GOSUB a label from C is really powerful.
It provides a level of interoperability that is just incredible.  What is
really needed, is a set of defines that would look up and store variables along
with GOTO'ing and GOSUB'ing a label.