gracelang / minigrace

Self-hosting compiler for the Grace programming language
39 stars 22 forks source link

Allow relative imports #297

Closed IsaacOscar closed 4 years ago

IsaacOscar commented 5 years ago

Imports now work as expective when using sub-directories. E.g. if you have files like this:

The path's in the "import" statements are now resolved relative to the file containg it. This fixes issue #295.

IsaacOscar commented 4 years ago

Thanks @apblack, it does introduce a new "bug": If I have files like this:

Perhaps we should use the OS to check if the files are at the same place (as we discussed in https://github.com/gracelang/minigrace/pull/296#issuecomment-503800663)

However, I don't think this is not a new bug that I introduced, is it already happens on master.

IsaacOscar commented 4 years ago

There seem to be two changes here. The first is that the compiled Javascript is intended to be always written to the same directory as the source. This is achieved by the manipulation of util.outDir on lines 229 and 247.

That change is simply to insure that if you import a module A/a.grace and that imports a module B/b.grace, then the path B/b.grace will be interpreted relative to A (the new value of util.outDir). As for output, it also has the side effect of putting the ".js" files next to the ".grace" ones (which is needed for things to work I think). I hadn't thought of how this will work if the user manually specifies --dir on the commandline though.

The second change is to index the gctCache by pathName rather than by moduleName. Presumably, the intent is to allow the import of two different modules with the same shortName.

No, that change is so that the full path of the module name is used when looking up GCT files, in particular it needs this path to find any .gct or .js files in the right place (as using the short name will look in the wrong place)

Allow the compilation of multiple modules with the same names was merely a side-effect of my changes (however due to issue #298 this doesn't work at run time).

apblack commented 4 years ago

I adopted a different solution to this problem in commit 63f25cc9a. There is also the problem of finding the compiled code at runtime; this is addressed in e14633abc. It's hard to write comprehensive tests for these fixes because there are so many variables: in particular, the value of GRACE_MODULE_PATH, and whether or not the compilation has a --dir option. I think that I've covered the main variables; if not, create a failing test and reopen the issue.