feature request: more sophisticated import semantics

[jfhbrook]

As far as I can tell, the current semantics for importing modules looks something like this:

1. Look for ./{{MODULE_NAME}}.yab in the current working directory
2. Look for {{MODULE_NAME}}.yab next to the file doing the import
3. Look for /usr/lib/{{MODULE_NAME}}.yab

This is definitely enough to get going with writing useful software! But it makes it challenging to distribute software as packages. For example, a package with native bindings might be structured as a directory with a {{PACKAGE_NAME}}/index.yab and {{PACKAGE_NAME}}/target/release/{{PACKAGE_NAME}}.so. If I wanted to make this work with the current system, I'd need to copy {{PACKAGE_NAME}}/index.yab to either live next to my_script.yab or at /usr/lib/{{PACKAGE_NAME}}.yab, and similarly move the DLL to /usr/lib/{{PACKAGE_NAME}}.so. This wouldn't really support multiple modules per package at all.

I had a few ideas for how I could make this form of distribution easier. The first was to make sure yabasic supported namespace imports, such as foo.bar.baz, which would import foo/bar/baz.yab. This might already be supported, but I haven't checked yet. The second is to introduce colon-separated library paths, similar to how java uses CLASSPATH. Between these two, I could at least structure code into packages and maintain a locally-scoped modules folder, with little-to-no breakage in existing behavior. If you can load DLLs by path relative to the .yab file, then DLLs can be distributed with their packages as well. While in here, separating the paths for DLLs and modules probably wouldn't hurt either - that would let us support python-style site-packages patterns.

Another idea is to adopt some patterns from node - so update the file search logic to check ./yab_modules/{{PACKAGE_NAME}}/index.yab, ../yab_modules/...., etc. This would be more likely to break peoples' existing scripts I figure, but could end up being pretty powerful.

I understand if you don't want to change the semantics of how modules are loaded in yabasic. But I get the feeling that this is something that's relatively flexible, so I wanted to ask about at least sketching out a loose spec. Who knows, maybe I can take a crack at implementing it, if I know what we're aiming for. So just putting this out there - what do you think?