Justin wrote:
Sounds cool. Can the host app comunicate with the scripts passing and returning vars or objects?
The short answer is, yes.
If you are asking whether you can pass values in and out whilst a script is running then yes, you can do it through various mechanisms.
The easiest option is to simply pass values in when invoking a script function and then retrieving any return value. That of course is a fundamental requirement for any script engine.

Incidentally, you do not need to invoke a full function in order to execute a script. minScript supports pre-compiled 'code snippets' which the host app can stash away and execute at any time and are intended for rapid and repeated execution etc. These snippets can then call into module functions and classes etc. The point is that you don't necessarily need to regard a script as a single large entity if you also make use of these snippets.
Second option is the fact that both the host app and scripts can set and retrieve the values of what we have called 'script variables'. These are top-level global variables (we have several levels of global variables). For example, the host app could create an array and assign it to a script variable and then this would be available to any script running under the relevant code object. This is a simple way of a host app communicating with a script etc.
Third option is the use of run-time functions. The host defines a run-time function which can be called by a script. Communication can thus be facilitated this way. In fact a run-time function can execute additional scripts if it so wishes - so scripts running within scripts!
Another more advanced option is through the use of what we have termed 'user-defined reference types'. These are similar to script classes (which minScript offers), but their definition and implementation sits in the Purebasic host app. For example, we have implemented arrays through the use of a suitable user-defined type (and script classes as it turns out!)
So if I use an array as an example, a script can create an integer array (for example) and assign it to a local variable. Whenever this variable is then acted on by a script (e.g. setting the value of one of the array elements) then control passes to the the host app (similar to a run-time function) in order for the relevant PB code to do it's thing!
This is an advanced option because user-defined types, for one thing, impact upon minScript's garbage collector and additional code has to be provided by the host to assist the garbage collector dispose of any 'wayward' instances of the underlying user-defined type. We had to create 'garbage collector extensions' for both arrays and script classes and these can be fiddly.
Don't let this last option put you off mind as very very few people would need to concern themselves with implementing a user-defined type. I fully intend to add hash maps (in the form of Javascript style objects) and this will be a relatively simple application of the aforementioned user-defined types. Once I have created them then all users of minScript will be able to use them.
There is one last way of a host app communicating with a script (and vise versa) and that is through a debugger - though any such communication is rather limited as I have deliberately not overloaded minScript's debugging capabilities. I made that mistake with eScript!
I hope that answers your question.