If you are willing to try and integrate minScript into an existing app (and without documentation!

) then I am more than happy to alter minScript in any way you need (within reason of course!

)
However, let me make sure I understand what you are after.
Are you saying that your users will themselves create runtime functions in Purebasic and that these should be accessible on a per-module basis so that i) no other module will even 'see' another module's run-time functions and, ii) function names can be repeated through different modules?
If so... interesting. That most certainly is not possible at the moment as I didn't envisage a need to have run-time functions which were anything but global throughout an application. I'd have to give that some thought as to the best way of implementing that. I am planning on making some adjustments to run-time functions anyhow so I may be able to kill two birds with one stone there.
There is a massive potential problem, however, with allowing your users to create run-time functions in PB (if I have this right) and that revolves around garbage collection since when using Purebasic to effectively extend minScript, you introduce all sorts of possibilities to create situations which our garbage collector cannot cope with. Such situations can arise if a run-time function creates additional resources such as allocating memory, opening files and so on. minScript will know nothing about such things.
One example is our own 'AllocateMemory()' run-time function.
Any script making use of this particular function which then crashes out because of a run-time error or simply forgets to release the allocated memory, then creates a memory leak.
Take the following script for example :
Code:
FUNCTION DoStuff(bufferSize)
DIM mem, a, b AS INTEGER
IF bufferSize
mem = ALLOCATEMEMORY(bufferSize)
IF mem
b = 10/a ;This is a division by zero!
FREEMEMORY(mem)
ENDIF
ENDIF
ENDFUNCTION
If the above script function was called then a run-time error will be generated at the line which causes a division by zero error. Execution will be halted before the FREEMEMORY() function has been invoked and thus we have a sizeable memory leak!

minScript will of course release the variables 'bufferSize', 'mem', 'a' and 'b', but it knows nothing about the memory allocated in a chunk of Purebasic code servicing the AllocateMemory() run-time function. On top of this, some 'sloppy' coders may even forget to use FREEMEMORY() in an otherwise perfectly running script.

Also, the design of the script may make it so that the appropriate FREEMEMORY() was called in a separate function and so on which of course makes automatic garbage collection of such dynamically allocated resources almost impossible. Almost, but not quite!
Now whilst there is a mechanism in place to clear up any such memory leaks, it really isn't a good option for you to expect your users to actually go down that 'non-trivial' path. You basically have to create what I have termed a garbage collector extension which is an advanced topic. I have created several for use in minScript (a simple one for AllocateMemory(), more complicated ones for arrays and hashmaps and a hugely complicated one for classes!

) Instead, you yourself (with my help in the first instance until the docs are complete) should perhaps create all such run-time functions which need to create dynamic resources (and thus potential memory leaks) and warn your users to only add run-time functions which do not themselves create additional dynamic resources unless they are prepared to create garbage collector extensions.
Mind you, as stated, the GC extension we created for AllocateMemory() was simple enough so perhaps I am being a bit pessimistic here.
Again, there was never any suggestion in my thinking that a user of a user of minScript would ever need to create a run-time function and so the thorny issue of garbage collection would only ever concern myself and immediate users of minScript such as yourself - not your users!

Even then, garbage collection is only an issue if you create run-time functions which may misbehave in this way.
Honestly, garbage collection (especially with class objects) nearly brought minScript crashing down on my own head... and it may well do yet!
