mkvsynth/mkvsynth — pull request #17 by lukechampine (2014-03-24 20:51:35+00:00)
Title: Add support for importing existing scripts

This change introduces support for importing existing Mkvsynth scripts into the current script. When the import statement is parsed, the interpreter will stop parsing the current script, parse the entire imported script, and then pick up where it left off. More technically, scripts are pushed onto a stack, and popped when they have been fully parsed. By traversing this stack on each import, the interpreter can detect circular import chains and throw an error if such a chain is detected.

The syntax for importing a script is exactly the same as importing a plugin: `import foo`. After parsing this statement, the interpreter will check the user's home directory for both `.config/mkvsynth/foo.mkvs` and `.confing/mkvsynth/libfoo.so`. An error will be thrown unless one (and only one) of these handles is valid.

This may feel a bit restrictive; it means that if you want to import a script, it *must* lie in `~/.config/mkvsynth/`. It wouldn't be too difficult to allow importing a file from an arbitrary location, given its full path. The problem is that such scripts are not portable: `import /home/luke/foo.mkvs` will fail if the user is not named luke.

The `import` syntax may become a bit confusing if I add support for importing specific functions from a plugin, such as `import foo.bar`. There is no easy way to import a single function from a script file, and I'm not sure it would be a good idea anyway. So this syntax would be valid for plugins and invalid for scripts, and that's ugly. I think the best solution is simply to not support importing individual functions.

One thing to think about for the future is how to handle dependencies. It would be cool if scripts could automatically download the scripts and plugins that they depend on, instead of forcing the user to seek out the required file, download it, and copy it to their plugin directory. Alternatively, the tool for packaging plugins could be programmed to generate "static" packages by automatically bundling the plugin with all its dependencies. This seems a lot simpler, and it also protects against the danger of dependencies 404'ing. Of course, I'm open to input here.