The goals

These are the main goals that I'm trying to achieve with this scripting library.

easy to use
light-weight
efficient
highly configurable
platform independent

Easy to use

For the application writer the library will be easy to use as the engine is able to directly call ordinary functions using the same data types as the host application. The application simply registers which functions it want the engine to be able to use, and then the engine does the rest. There is no need to write complicated proxy functions that convert variants to usable data types.

The script writer will find a language syntax common to many other languages, such as JavaScript, C++, C# etc.

Exception handling with describing error messages makes writing and debugging scripts easier. It also makes it easier to write stable scripts. The engine also supports stepping through the scripts, line by line, for easier debugging.

The library will perform garbage collection as far as possible. However, as the library will not have direct control over the application's objects it will only be able to treat its own internal objects such as strings and arrays. The engine will however be able to work closely with the applications memory management using reference counting on the objects if necessary.

Light-weight

The library will be as light-weight as possible, this means that it will not have a lot of built-in functionality that only a few applications use. Should an application need these thing it will be able to add them as it sees fit. The library won't be an object oriented language, in that classes can be created and inherited from one another. The library will however be able to use the application's own classes, by calling member functions and accessing member variables.

The library is not meant to be able to write complete applications, it is meant to be used as a mean to move some of the application control to the hands of the users.

Efficient

The library will be as efficient as it can be. This means that the script code is not interpreted at run-time, but instead compiled into byte code as the scripts are loaded. The byte code is then executed by the virtual machine.

Because the virtual machine uses the same data types as the host application there will be a minimal overhead when calling application provided functions.

Highly configurable

No two applications need the exact same thing from a scripting language, therefore the library must be highly configurable. This will be obtained by allowing the application to register system functions that the scripts may use, it can also register new data types, that may have their own member functions and properties. Even the script's operators will be overridable.

Platform independent

The library is meant to be platform independent, but due to lack of development environments I'm not able to verify this fact. Help from the community is appreciated. I will try as far as possible to use only code that is standard to the C++ language, and not special to any specific compiler.