While thinking about package systems in https://github.com/LightAndLight/ipso/issues/17, I've decided that the first step should be a way to resolve imports via command line arguments. A more sophisticated package system could be expressed in terms of this simpler interface (but doesn't have to be implemented using it).
Examples
ipso --module a=/path/to/file.ipso test.ipso
Meaning: a module named a with the contents of /path/to/file.ipso should be available to test.ipso.
ipso --module a.b=/path/to/file.ipso test.ipso
Meaning: a module named a containing a submodule named b which has the contents of /path/to/file.ipso should be available to test.ipso.
ipso --module a=/path/to/file1.ipso --module a:b=/path/to/file2.ipso test.ipso
Meaning: a module named a with the contents of /path/to/file1.ipso should be available to test.ipso, and a module named b with the contents of /path/to/file2.ipso should be made available to module a (/path/to/file1.ipso).
ipso --module a=/path/to/file1.ipso --module a.b=/path/to/file2.ipso test.ipso
Meaning: the combination of cases 1 and 2, but only succeeds if a (/path/to/file1.ipso) has no definition for named b. If a does define b, then a.b is ambiguous: it refers to both the b definition in a (/path/to/file1.ipso) and the submodule b (/path/to/file2.ipso) in a.
ipso --module a:b=/path/to/file2.ipso test.ipso
Meaning: redundant. No module a has been provided, so there is no need to provide a module b to module a.
While thinking about package systems in https://github.com/LightAndLight/ipso/issues/17, I've decided that the first step should be a way to resolve imports via command line arguments. A more sophisticated package system could be expressed in terms of this simpler interface (but doesn't have to be implemented using it).
Examples
ipso --module a=/path/to/file.ipso test.ipso
Meaning: a module named
a
with the contents of/path/to/file.ipso
should be available totest.ipso
.ipso --module a.b=/path/to/file.ipso test.ipso
Meaning: a module named
a
containing a submodule namedb
which has the contents of/path/to/file.ipso
should be available totest.ipso
.ipso --module a=/path/to/file1.ipso --module a:b=/path/to/file2.ipso test.ipso
Meaning: a module named
a
with the contents of/path/to/file1.ipso
should be available totest.ipso
, and a module namedb
with the contents of/path/to/file2.ipso
should be made available to modulea
(/path/to/file1.ipso
).ipso --module a=/path/to/file1.ipso --module a.b=/path/to/file2.ipso test.ipso
Meaning: the combination of cases 1 and 2, but only succeeds if
a
(/path/to/file1.ipso
) has no definition for namedb
. Ifa
does defineb
, thena.b
is ambiguous: it refers to both theb
definition ina
(/path/to/file1.ipso
) and the submoduleb
(/path/to/file2.ipso
) ina
.ipso --module a:b=/path/to/file2.ipso test.ipso
Meaning: redundant. No module
a
has been provided, so there is no need to provide a moduleb
to modulea
.