Imports
How to import functions from other Daphne scripts
Example usage:
UserConfig.json
now has a new field daphnedsl_import_paths
, which maps e.g., library names to a list of paths, see example:
"daphnedsl_import_paths":
{
"default_dirs": ["test/api/cli/import/sandbox", "some/other/path"],
"algorithms": ["test/api/cli/import/sandbox/algos"]
}
NOTE: default_dirs
can hold many paths and it will look for the one specified file in each, whereas any other library names have a list consisting of one directory, from which all files will be imported (can be easily extended to multiple directories).
Example:
The first import will first check if the relative path exists, then it will look for it relative to paths in default_dirs
. If the specified file exists for more than one relative path, an error will be thrown.
The second import goes to algorithms
directory from UserConfig
and imports all files from it.
Paths from UserConfig
get to DaphneDSLVisitor
from daphne.cpp
via DaphneUserConfig
.
Variable name collision resolution: Whenever we stumble upon equal prefixes (e.g., files with the same name in different directories), a parent directory of the file where conflict is detected is prepended before prefix.
Example:
NOTE: the parent directory may be prepended even though you never specified it (e.g., the import script is in the same directory as the original script).
Example:
Libraries and aliases: Currently, the following example is allowed:
import "algorithms";
import "sandbox/b.daphne" as "algorithms";
print(algorithms.x);
print(algorithms.kmeans1.someVar);
Even though both prefixes will begin with algorithms.
, the entire library content's prefix is extended with filenames. It is up to user to not confuse yourself.
Cascade imports:
Any variables/functions imported into the script we are currently importing will be discarded.
Example import scheme: A<-B<-C
. A imports B, B imports C. B uses some vars/functions from C, but A doesn't "see" any of C's content.