Module imports are not resolved from module root

[orlade-anz]

Please do not post any internal, closed source snippets on this public issue tracker!

Description

//{/path/to/foo} is supposed to import foo.arrai from the path path/to/foo.arrai relative to the root of the module (i.e. the go.mod file). However it appears to be evaling relative to the current directory.

Steps to Reproduce

1. mkdir -p path/to
2. echo "1" > path/to/bar.arrai
3. echo "//{/path/to/bar}" > path/to/foo.arrai
4. arrai run path/to/foo.arrai

Expected behavior

1

Actual behavior

path/to/foo.arrai:1:4:
//{/path/to/bar} 

The import //{/path/to/bar} is being parsed/interpreted as path/to/path/to/bar. The path/to/ prefix of the arrai run command is somehow prepended to the string in the //{/...} import statement.

This doesn't happen for //{./...} imports.

Your Environment

$ arrai info
Version    : DIRTY-v0.141.0
Git commit : 91069d5189a82963e545855fd24ab144e61c3348
Date       : 2020-08-25T04:16:20Z
OS/arch    : darwin/amd64
Go version : go1.14.4 darwin/amd64

[orlade-anz]

An apparent fix is to change syntax/compile.go from

rel.NewString([]rune(path.Join(pc.SourceDir, filepath))),

to

rel.NewString([]rune(filepath)),

This works for arrai run but may well break arrai eval. TBC.

[orlade-anz]

... not only is the //{/...} module import dodgy, it also somehow pollutes the context of subsequent imports. In cases where a module import does work, a subsequent relative //{./...} import will fail, searching in the module root instead of relative to the script or to working directory.