If code refers to an object that isn't known, Io will attempt to find the file containing that object and import it. For example, if we refer to Foo and Foo isn't known yet, then Io will try to locate Foo.io and import it.
From http://iolanguage.com/paste/p/ed2ba4148.html:
Io> SomeObject
/* If SomeObject isn't found in the lookup chain, the Importer will
be invoked to look for a SomeObject.io in its search paths. If that
file is found, it'll be loaded and evaluated. */
Io> SomeObject type
==> SomeObject
/* We now have loaded the SomeObject object. */
Foo.io may have multiple objects, which will all be imported. E.g. a Foo.io containing objects Foo and Bar will import both. A Foo.io that does not contain an object Foo will raise an error; however, if the error is recoverable, then the objects in Foo.io will still be imported.
For example, this is what happens when trying to import a file Foo.io with names foo and bar (Io 20060502):
Io> Foo Exception: Importer slot 'Foo' missing after file load --------- Object Foo doString 2 Io> foo #=> 42 Io> bar #=> 133
Importing is handled by the Importer object.
By default, files are looked for in the current directory. However, this can be changed by manipulating the Importer paths list. For example, if we have the following file structure:
main.io lib/Foo.io
then code in main.io referring to Foo won't work, because the lib directory is not searched. However, doing Importer paths append("lib") will remedy this. (Compare to sys.path in Python.) Alternatively, use Importer addSearchPath("lib").
/* TODO: doFile */