search

LightAndLight / ipso

A functional scripting language.
https://ipso.dev
16 stars 1 forks source link

Configurable import resolution #381

Open LightAndLight opened 1 year ago

LightAndLight commented 1 year ago

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

  1. 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.

  2. 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.

  3. 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).

  4. 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.

  5. 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.