current stable:
cvs (0.99.7)
  Home / News
  The Team

  Source Tarball
  CVS Web View
  Misc. Files

The Manual
  Download [html]
  Download [pdf]
  View Online
  Download [html]
  View Online
  Script Examples

Developer Guide
  Download [html]
  Download [pdf]
  View Online
Ferite C API
  Download [html]
  View Online

Open Source Approved

SourceForge Logo - browse the Keyword Map of

[previous] Regular Expressions[up][toc]Application Interface [next]

Uses and Include

Both the uses and the include() instructions tell ferite to include another script within the current one. The main difference is that uses is a compile time directive and include() is a runtime directive.

It is VERY important to note a specific behavior with these two language constructs. When a script is imported - the script importing it obtains: global variables, classes, functions, namespaces, but NOT and I repeat NOT the anonymous start function. By this I mean the code that gets run when running the script. The logic behind this apparent maddness is that it allows the anonymous start function to be used to write test cases or examples that go with the imported script. This means that if you modify something within the imported script (say it's from a library of scripts) - testing it is just a case of running it through ferite. Or if someone wants an example on how to use it's features - just look at the script being imported. This reduces the number of files that need to be distributed in libraries of scripts and allow distinct test cases/examples not to be lost (and stay current to the API they are against).


The uses keyword is used to import API from other external modules and scripts. The uses keyword is a compile time directive and provides the method for building up the environment. It can either pull in an external module, or compile in another script. The syntax is as follows:

    uses "name of module or script file", ...;

"name of module or script file"

The name must be in quotes. When ferite gets this call it will do the following: if there is no extension it will try loading a script in the system's library paths trying the extensions '.fe', '.fec' and '.feh'. The paths for the native and scripts are defined by the parent application. If an extension is given, ferite will check to see if it equals .lib, if it does it will load the correct native module, eg. uses "array.lib"; will cause ferite to load under unices and array.dll under windows. This gives a platform independant method to tell ferite to load a native library. This is the method used to load a native module. If it doesn't equal .lib, ferite will treat it as a script and load it.

In the case of the ferite command line application, $prefix/lib/ferite is searched for scripts plus any directories that are added on the command line by using the -I flag. Native modules are placed in $prefix/lib/ferite/$platform, where $platform is of the form os-cpu.

If either the script or the module can't be found the compilation of the script will cease with an error. It is suggested that these are placed at the top of the script (although this is not a requirement).


include() operates the same way as uses, except that it can currently only import other scripts. Once the call has been made - the facilities provided by the imported script can be used. It should be noted that the return value from the include() call is the return of the main method when the script is loaded. This allows items to be passed to the parent script.

    include ( "someScript.fe" );

[previous] Regular Expressions[up][toc]Application Interface [next]
ferite et al © 2000-2004, Chris Ross