HISTORY of changes

	- Kenneth Johansson reported that strings containing "//" did not
	  work properly. I discovered that when FPL was passing code, it
	  did read comments within strings as if they really were comments
	  and could thereby miss the ending quote. Removed "feature"...

	- The file caching did not work as stated in the manual. The file
	  was cached as default whatever the fplInit() tag
	  'FPLTAG_CACHEALLFILES' told. Should work now.

	- Had to rearrange some code when generating the FPL_GENERAL_ERROR
	  call since OS/2 obviously had some trouble with doing as I was
	  doing! The previous code:

		int foo=5;
		void **bar = &foo;
		printf("%d", (int)bar[0]);

	  did work under AmigaDOS and UNIX outputting '5'. Under OS/2, the
	  output become a very large number. The solution was to make it:

		int foo=5;
		void *bar[1];
		bar[0] = (void *)foo;
		printf("%d", (int)bar[0]);


	- I have removed all allowances to change FPL in this version.
	  Previously, FPL was released under GNU license, but so is no
	  longer the case! FPL is still Freeware, but may not be changed
	  by anyone, except for porting procedures.

	- FPLTAG_STRING_RETURN is added. This is a fplExecuteXXXX() tag
	  and it should be followed by a pointer to a char pointer.
	  This tells FPL that the highest program level (the "main" level)
	  is allowed to return a string which will be received in this
	  pointer. exit() will be able to return strings from all levels.
	  The returned string can be read and the FPL_STRLEN macro can be
	  used to get the length of the string. The string must be freed
	  with fplFreeString() (or will be done at 'fplFree()').
	  Programs that are using this tag cannot return an int.

	- fplAllocString() allocates memory for sending a string to FPL.
	  That is to prevent code like:
		{
		  char *data= malloc(1000);
		  strcpy(data, otherdata);
		  fplSendTags(anchor, FPLSEND_STRING, data, TAG_DONE);
		  free(data);
		}

	  The enormous overhead when FPL also allocates and copies the
	  data is avoided by the new:
		{
		  char *data = fplAllocString(anchor, 1000);
		  strcpy(data, otherdata);
		  fplSendTags(anchor, FPLSEND_STRING, data,
				      FPLSEND_DONTCOPY_STRING, TRUE,
				      TAG_DONE);
		}

	- Currently I know about eight software projects around the globe
	  that are using fpl.library (four of them are BBS programs!).
	  Please, do notify me if you are using fpl.library and tell me
	  about your program. I would also encourage at least users
	  in Sweden to get the echo mail message area R20_FPL from us -
	  fido address 2:201/328 (The Holy Grail +46-(0)8-6121258). (It
	  will hopefully get on the backbone as soon as possible!)

	- Previous versions couldn't cache string-arrays, it ended up in
	  serious enforcer-hits!

	- I split up the .guide file into FPLuser.guide and FPLlib.guide.
	  All library functions are now put into fpl.doc which is in the
	  good old autodoc format. Docs are now found in the "docs" drawer
	  from the FPL root. The FPL root should be assigned FPL: to make
	  the cross-reference between the two .guide files work. PLEASE,
	  do report manual bugs!

	- As reported by Niclas Emdelius, FPLTAG_PROGNAME did not work
	  correctly.

5.12	- (931217)
	  The library grew larger because of the compiler support that are
	  being inserted step by step. A future version is ment to be able
	  to compile and to run compiled code.

	- Corrected some strange behaviours when defining or prototyping
	  function names that already are used/defined. Now you can't
	  define function names with names that exist as internal or
	  external functions or keyword names. A function can only be
	  defined once with one name, a second try will result in error.
	  A Kjell Ericson report.

	- Strings containing \" (backslash quote) really messed things up.
	  Fixed! A Kjell Ericson report.

	- Made all tagfunctions have proper 'tagcall' pragmas. Use all
	  functions that accepts tags as their last parameter as:
	  <FunctionName>Tags() and you won't need any glue-code when
	  compiling with SAS/C and using tags.

	- Fixed the FPLTAG_INTERPRET tag a bit more since it didn't work...
	  Thanks again to Lasse Mickos.

5.10	- FPLTAG_INTERPRET now works even if there is no real start of the
          code. Thanks to Lasse Mickos for reporting this bug.

	- FPLTAG_STOREGLOBALS has lost its point and now FPLTAG_CACHEFILE
	  fully decides whether to store symbols.

	- The "struct fplArgument" has been extended with one more member.
	  "ret" will contain the expected return type. All functions that
	  return either 'int' or 'string' will find FPL_INTARG or
	  FPL_STRARG there, but functions returning FPL_OPTARG can find
	  either one depending on the expression in which the function is
	  being used. DO RETURN THE TYPE THAT IS EXPTECTED, OTHERWISE YOU
	  CONFUSE THE INTERPRETER!! If the "ret" is not what you expteced,
	  do not hesitate to return an FPL syntax error, and if the "ret"
	  field matches FPL_OPTARG, please return something to help the
	  interpreter find the type of the expression.

	  Earlier compilings will of course still work 100%.

	- Optional return types will now be recognized slightly different.
	  If an expression expects a certain kind of return type, eg:
	  "int a = FooBar();" (the expression to the right of the assign
	  character is *expected* to return an int), that will be the
	  default interpretation of the returned optional return type. If
	  the returned type didn't match with the variable receiving it,
	  a zero, for integers, or a zero length string ("") will be the
	  result.

	- FPLSEND_GETRETURNCODE will only be able to call and get a proper
	  result until a new fplExecute#?() call is made. It is then set
	  to zero (0). A Kjell Ericson report.

	- The tags FPLTAG_CACHEFILE and FPLTAG_CACHEALLFILES have been
	  modified. Previously they accepted a boolean data, but now they
	  should be used using the more appropriate FPLCACHE defines.
	  They are as following:

	  FPLCACHE_NONE		- Do not cache under any circumstances.
	  FPLCACHE_ALWAYS	- Cache if any symbols were global.
	  FPLCACHE_EXPORTS	- Cache if any symbols were exported.

	  Earlier code will still work if it used 0 as FALSE and 1 as TRUE.

	- Expressions using a numerical variable and then a ">=" or "<="
	  operator did act is if it was written ">>=" or "<<="!!!
	  Reported by Niclas Emdelius.

	- Using '}' or '{' in declared functions, or other parts which
	  should be passed in any way, did cause an FPL error. Kjell
	  Ericson reported it.

	- Finding ASCII 10 inside a string did not work properly.
	  Preprocessing a "\n" did make a zero length string when
	  interpreted. Found by Kjell Ericson.

	- Functions that are defined to have one argument but are called
	  with two now results in a 'syntax error' message instead of the
	  earlier 'missing parenthesis'.

	- "\x" must be followed by at least one hexadecimal digit or
	  fail with a syntax error.

	- Expressions are now slightly faster interpreted.

	- Do notice that I'm now available for email at dast@sth.frontec.se!!!

v5.8	- strcmp("foo", "foobar"); did act as if this is a match!
	  Reported by Niclas Emdelius.

	- Executed nested files with global/exported symbols could end up
	  in a never-ending loop...

v5.7	- (930912)

	- FPL now supports external functions with optional return types.
	  FPL_OPTARG should now be a valid return code type of an external
	  function. If this is used, FPL will do its best to determine the
	  right return type. Help this out by always fplSend() a return
	  value when using the opitional return type since FPL builts its
	  guess heavliy upon that type.

	- The "==" bug just became different, but now I think I have
	  removed that feature for ever!

v5.6	- (930908)

	- I hopefully removed that nasty bug that sometimes made FPL crash
	  when the interface funtion doesn't fplSend() any return value.

	- Using a string in a (o)ptional parameter argument, did in certain
	  circumstances return a NULL pointer instead of a zero length
	  string, which was not described in the manual. Now it's corrected
	  and returns a zero length string.

	- An integer as last parameter in a function call, combined with a
	  "==" comparison like: "if(foobar(hello)==12)" was giving an
	  "illegal assign error" since FPL tried to interpret ")=" as some
	  kind of compound assign! Fixed.

v5.5	- (930827)

	- The itoc() function was added today. This could be done
	  very easy by external function(s), but I think that FPL needs
	  that to be more independent.

	- (930824) The '!=' operator works now.

	- FPL now supports the #line - instruction! See FPL.guide regarding
	  preprocessing, line control and the FPLSEND_GETVIRLINE and
	  FPLSEND_GETVIRFILE tags.

	- Back from a long vacation in South East Asia.

-----------------------------------------------------------------------------


TODO (ideas to make reality by me, by you or by no one)

	- More C in the language. (I'm gonna make this a 100% C interpreter
	  one day, just wait!)
	  * "switch"
	  * proper expression abortions (the ?, :, &&, || operators)
	  * structs
 	  * floating point variables and expressions

	- Program tokenizer for increased execution speed. (Under development)