Allow applications to control the loading of files.

[luauser32167]

Currently scripts can load other script files using the import statement:

import (
    "relatiive/path/to/moduleA.um";
    "X:\\absolute\\path\\on\\windows\\moduleB.um";
)

this is great for the Umka interpreter (umka.exe), but applications usually want to load files from specific directories on the file system, or maybe even from an application specific archive file.

One way to enable this would be to add a umkaInit2 function that also takes an "opaque loader data" pointer and a "loader function" that is called for each string given to the import statement.

typedef char* (*UmkaLoadFunc)(void* loadFnData, char const* importPath);

bool umkaInit2(void* umka, char const* fileName, char const* sourceString, int storageSize, int stackSize, int argc, char **argv, void* loadFnData, UmkaLoadFunc loadFn);

If UmkaLoadFunc signals an error, by returning NULL, then the compilation stops, otherwise it returns the content of the loaded file. The returned value is now owned by umka (i.e it is malloc-ed by the application but free-ed by umka).

The current umkaInit function would call umkaInit2 with a default UmkaLoadFunc.

The many parameters of umkaInit could probably also be compressed in an UmkaConfig struct, thus eliminating the need for introducing a new umkaInit2 function.

[marekmaskarinec]

There is umkaAddModule, which allows you to add modules from string. Look at how tophat does it.

[vtereshkov]

Agree with @marekmaskarinec. @luauser32167, please look at umkaAddModule() and close the issue if this is what you are looking for.

[luauser32167]

umkaAddModule allows applications to eagerly preload certain modules, but it does not prevent scripts from loading other modules from anywhere on the file system.

The eager preloading of modules might not be desirable, when a script never references a module, its preloading would be a waste.

[vtereshkov]

@luauser32167 Loading prevention is not planned unless a large enough project requires it. This issue, as well as some others, implies that you are expecting to have "Umka in a sandbox". I have never had such requirements and cannot see real use cases for this.

[luauser32167]

This issue, as well as some others, implies that you are expecting to have "Umka in a sandbox". I have never had such requirements and cannot see real use cases for this.

First sentence from the README

Umka is a statically typed embeddable scripting language.

Being an embeddable scripting language implies that the application that embeds it is in control and can sandbox as much as it wants. Otherwise, potential users of the library would go to some other dynamically typed language implementation that does give them full control. I would rather see them use Umka, because its a nicely designed language, and more importantly, it's statically typed.

[marekmaskarinec]

but it does not prevent scripts from loading other modules from anywhere on the file system

What would be the problem with user scripts loading modules anywhere on the filesystem?

[luauser32167]

Could be totally harmless or launching the nukes kind of dangerous, who knows.

At the very least, it can be used to disclose information about the existence of files.

import "C:\\Windows\\Fonts\\Ubuntu-Regular.ttf"
fn main() { }

If the error is "Cannot open file XXX", the file does not exist (fopen returned null).