FUTURE of FPL

  Here follows a list with some of my intentions for the future of FPL.
They may change from one day to the next, but these are the items that feel
are most important (in an approximate order of importance):

* "Funclibs", add compiled functions to the list of FPL functions... This is
  already far developed and has already run nicely on machines in testing!
  Lookout for the GUI funclib for Amiga!

* FPLTAG_HOOK_LOAD, replace FPL's load functions. Enable compressed/encrypted
  programs or add path searching for programs or...

* FPLSEND_WATCH_SYMBOL. Get more information about a specific FPL symbol.

* (AMIGA) StackSwap() swap stack i a neat way. New flag options is also on
  its way: FPLTAG_HANDSOFF_STACK which will make FPL give the host program
  its stack back when the interface program is called. Thus enabling that
  program to use stack checkings and expansions as much as it pleases...

* switch() statement support including strings...

* some kind of locale support to make error string appear in the user's
  native language. Amiga has wonderful support (V38+) for this, but how
  should I do this system independent?

* (AMIGA) ARexx library emulator that can call and take advantage of ARexx
  libraries (libraries done to be called from ARexx). Will most likely be
  implemented as a funclib.

* Tokenizer/compiler (under development, will not be implemented until FPL
  is more stable and not expands this much!).
  
* Make 'char' and 'short' variables and arrays take no more memory than
  they should. (8 resp. 16 bits each.)
  
* Much more external variable control and function syntax reading.
  
* Pointers will be implemented. At first only to all the numeric
  variable types that exist today, 'int', 'long', 'char' and 'short'.
  Of course any number of pointer levels. such as "char *********p;".
  
* malloc() and a lot of other clean and pure C library functions
  will be added.
  
* Structures.
  
* Float variables and expressions
  
* Reading SAS/C pragma files to be able to call AmigaDOS shared
  libraries straight from FPL.
  
* FPL symbolic debugger. This will be able to use together with any
  software using FPL! I think I will get some help coding this...
  
* Storing all local symbol information in some kind of simulated
  stack to be able to call direct function calls to absolute addresses
  in memory to functions refering to data stored in the FPL program.
  Adding such functions will have to be done in some kind of
  OpenLibrary() way, or like an OS/2 and UNIX shared library function
  access solution (setting up a function that associates function
  identifiers with absolute memory addresses). An already working
  software with FPL interface should be able to call another compiled
  program using this function. No interpreting overhead!!!
  
* Now we should be able to interpret any C program with only a small
  preparation.
