Simple conditional compiles are desireable to 

* control things like password logging with a single switch, preferrably in
  the configuration file, without doing all the tests and jumps at run time

* make function calls dependent on whether the function is actually defined

So, we propose the following mechanisms:

* All text between any nonquoted '$' and the next $ (scanned without regard for
  quoting) is taken as a compiler pragma, that is, interpreted by the compiler
  rather than translated into stack machine bytecode

* Create a compiler pragma 'if', that takes the following form:

$if EAP
  or EAP-Message exists and EAP, 
$

  which means: if the symbol after 'if' exists (in function table, interface
  table, dictionary or macro table), compile the remaining text of the pragma
  as normal, else ignore it.

* Create a compiler pragma 'set' that takes the following forms:

$set DOEAP$

$set EAPSTATEMENT or EAP-Message-Exists and EAP,$

  which means: create a name in the macro table containing optional text

* Create a compiler pragma 'get' that takes the following form:

$get EAPSTATEMENT$

  which means: if the macro after the 'get' exists, replace the text between
  dollars with the text of the macro, else ignore the pragma. 
  
  We use a 'get' to avoid adding the macro namespace to the pragmas, which
  would both create the possibility of clashes if we expand the pragmas and
  remove the possibility of complaining about unrecognised pragmas.


===

Separating namespaces should be done more extensively; it removes
potential for user errors and makes things more readable.

Eg. take away the function and interface namespace from the rest:

	str="select * from data where ..."
	str="str,User-Name",
	call Sql,
	delall str,

	or User-Password exists and call PAP,

A problem is that we start to introduce more grammar this way. The only grammar
used to be operators and terms, but in the above, 'call' isn't a unary prefix
operator of any kind, but a reserved word that changes the parse context.

The only place where we do that now is in function definitions and includes,
and I think we should keep it that way.

Conclusion: don't go down this route.

===

What we should do though is that if a term is optional, make a non-term break
the subexpression, so that we can do away with the parentized function and
interface calls. It's completely unclear /why/ the following text has them
parentized:

  result exists 
  or User-Password exists and (PAP)
  or CHAP-Password exists and (CHAP)
  or EAP-Message exists and (EAP), 

(answer: it's just to avoid writing one of the following:)

  result exists 
  or User-Password exists and PAP 0
  or CHAP-Password exists and CHAP 0
  or EAP-Message exists and EAP,

(which creates useless immediate pushes, or the way too C-like)

  result exists 
  or User-Password exists and PAP()
  or CHAP-Password exists and CHAP()
  or EAP-Message exists and EAP,

In these cases, 'EAP' doesn't need the 0 or the parens because the comma
is allowed in context NON and simply returns in that case, as it's the operator
with the lowest precedence.

How to implement? If we are in 'non' context, and we haven't found a suitable
term or operator, make the parent try again by returning and having the parent
continue.

Note that we can only do that if a. parent required NON, and b. we're not at
top level.

Eg. make API test for <= 0 to detect errors instead of -1. 
If req_ctx is NON and we have a not found situation, simply return.

However, when do we know ret == 0 is wrong? Do we need to test the source left?
Or, don't pass 'NON' as req_ctx? We should pass 'TOP' perhaps, which is treated
as NON in terms of popping, but not in terms of being optional.

Or vice versa; pass OPT for optional subexpressions; treat those as NON in 
terms of popping if we have anything, but allow return if we haven't found
any term.



===

We should probably make 'include' a pragma too. Not function definitions; they
do emit code and are part of the language. Include is language transparent.
An includestr would be lovely too; instead of including in a compiler context,
it would do a completely binary pushstr using the file contents. Excellent for
storing secrets and whatnot.

===

We should implement a proper symbol table, with the following types:

- interface (added by parent only)
- function (added by parent, compiler or earlier compile)

and a separate macro table.

===

Implement lists by allowing terms in contexts != NON, doing pushes that set
the 'link to item below' flag at run time.


