When you encounter a DO or an IMPORT of a relative path in a script, we've been assuming that the most convenient interpretation of that would be to have it run relative to the script's location.
I think we need to stop changing the working directory on DO
We no longer use DO for breaking scripts into components, because the module system is starting to work...and it will only work better as time goes on.
So the idea of DO is now that it is a script that is like a utility, that takes command-line arguments of what it is to operate on.
The person who invokes a DO--like the person who invokes a script from a command-line--has a concept of the current path. The filenames they use are relative to their concept of the path, not the concept of the script. When running from the command line you may not really know or care where the script is--it could be somewhere on the path--why would you relativize your paths to this unknown location?
We Can Use New Datatypes Like @p/a/t.h and @tup.le
Files passed on the command line can have pretty gnarly names with arbitrary composition in them...spaces, starting with digits, etc.
When you DO or IMPORT a script the name is likely more tame.
What if we said you could IMPORT an @xxx and it would turn that into a path and relativize it?
import %my-lib.r ; relative to WHAT-DIR
import @my-lib.r ; relative to system.script.path
Having distinct intents for IMPORT isn't as useful as distinct intents for DO.
If we were willing to establish these two intents, we could make it a property of READ... so this ceases to be anything specific to IMPORT or DO.
Questions, Comments, Suggestions?
Right now the @-path idea looks like a pretty decent idea. I think it would solve a lot of pain points I've been dealing with in trying to write GitHub Actions that are getting confused about the directories.