Changing the semantics of relative imports in `morte`

[Gabriella439]

I was planning on changing relative imports in morte to behave differently and I'm opening up this issue ahead of time to solicit input in case anybody objects to my plans.

Currently, all imports are resolved relative to the directory that morte is run from. For example, suppose that you have the following files:

$ cat foo/bar
#foo/baz
$ cat foo/baz
*
$ morte < foo/bar
□

*

Currently, the #foo/baz relative import in the foo/bar file is resolved relative to where you run the morte command from, so if you cd to any other directory then you can no longer foo/bar. Similarly, if you rename the foo directory or serve it from a web server then you can no longer use foo/bar.

The proposal is to fix relative imports so that morte packages can be easily relocated, renamed, or used from any directory and easily served from a web endpoint without any modifications. To do this, the following changes would be made to the semantics of relative imports in morte:

• relative imports would now always be legal (even within remote imports; previously remote imports could only reference absolute remote imports)
• a relative import within an imported local file is now relative to the file's path
• a relative import within an imported URL is relative to the URL

To be precise, morte will not do any canonicalization, so if you import a remote expression from:

#http://example.com/foo

... and that expression had a relative import of:

#../bar

... then that relative import would translate into a second request to #http://example.com/foo/../bar. The server would be responsible for deciding how to interpret that path and morte will not pre-canonicalize the path.

Absolute imports would be unaffected and they would still be forbidden within remote imports. I might even outright forbid absolute imports, period, at some point in the future, but that's outside of the scope of this issue.

After this change, you would be able to take any morte package and host it on a remote endpoint with no modifications. Vice versa, any user could download all the files hosted on the web endpoint locally.

The main benefit of this change is that it will be much easier to upload and download morte packages (trivial, actually). The main disadvantage is that it's a highly breaking change. However, overall I think the breakage is not a big deal given that morte is not a widely adopted language anyway. I only know of one morte project at the moment, which is this one so I'm pinging @5HT and @zraffer on this issue since they will certainly be affected by this change.

[5HT]

We already did a compatibility breakage:

1. We avoid haskell style terminals like (++) instead we use [++] for this. As we don't want to count brackets in tokenizer.
2. We specify full path to term without shortcuts like #List/@ and avoid #List.

So we have some king of Mortet support however it should be clarified that we have these two issues and maybe it will count. We actually imported Morte's base library manually with respect to these two notices:

https://github.com/groupoid/om/tree/master/priv/normal

Conclusion: feel free to modify Morte's syntax.

P.S. Also we don't support #http monikers yet and probably will want to have something like our internal language behind # mark.