Developing the import system

Posted: December 19th, 2009 | Author: Mars | Filed under: Uncategorized | 5 Comments »

I’ve implemented a little more of the module import system. The import statement has gained a from clause, which lets you specify the subdirectory where the desired module can be found. This search is always relative to your program’s main file, no matter which component you put it in. Imagine that your project had the following file structure, with foo.radian as the main file:

foo:
    foo.radian
    bar.radian
    sub:
        baz.radian
        quux.radian

From any file in this project, you could import modules like this:

import bar
import baz from sub
import quux from sub

That is, imports from baz.radian start from the foo directory too, not the sub directory. I’ve done it this way so that you can break a project up into subdirectories which can then refer to each other’s contents.

There is one special subdirectory name: if you import a module from radian, the compiler will look for it in the common library directory. This directory will contain containers, formatters, IO services, and other utilities that are likely to be useful in nearly every program. I do not intend that this directory will be extended by the user – it should be read-only, if at all possible, associated firmly with a single version of the Radian language distribution.

5 Comments on “Developing the import system”

  1. 1 Will said at 06:19 on December 22nd, 2009:

    What if you’d like to have more than one program share a common folder of code? It seems like there’s no way to refer to a directory above the level of the program’s main file.

  2. 2 mars said at 08:41 on December 22nd, 2009:

    It is true, I have not introduced any such mechanism yet. I have a few ideas, but a clear winner has yet to emerge.

    It seems to me that there is, or ought to be, a clear distinction between code that is part of one specific program, and code that is part of some library the program is using. I’d like each library to be an independent unit; its imports should be relative to its own directory, and not extend to the program using it.

    I want to avoid the typical “big box of plugins” model, where all libraries have to live in some special directory. Instead I’d rather require each project directory to contain its libraries, and let people use symlinks if they want to share a common copy of the library somewhere.

    Not sure how libraries should refer to each other. Some kind of package-ID string might be good, perhaps with a version number.

  3. 3 Will said at 05:58 on December 23rd, 2009:

    That makes sense. I’d actually considered the symlink idea, after I made my first comment, and it seems like it might work pretty well.

  4. 4 Aaron Ballman said at 16:20 on December 29th, 2009:

    Keep in mind that symlinks aren’t particularly common on Windows. It would be a very…odd… way to do things on that platform.

  5. 5 mars said at 09:12 on December 30th, 2009:

    What would be a more normal way of doing it on Windows? Would you need some kind of absolute file path?

    I would be more OK with having some kind of magic central library if programs identified their dependencies by some kind of ID+version combo instead of just a name. I think it would also be important to search the project folder before searching the central library, so you could override whatever might happen to live in the library by putting a specific copy in the project.