I'm moving ahead with DO of a script (or running on the command line) not changing the current working directory. It's an important and overdue change.
So if you run:
/home/me$ r3 /usr/local/scripts/something.r ./foo.txt
something.r is called it will still be in
/home/me, and it will resolve foo.txt to
/home/me/foo.txt by default. That's good.
But if you then have:
Rebol [File: %something.r] import %utilities.r
Then this will look for utilities.r in
/home/me as well.
I think that is the correct behavior for a relative %file path. So the real issue is just that there needs to be another syntax to tell IMPORT to look relative to SYSTEM.SCRIPT.PATH.
TL;DR: I Think This Should Be TAG!
This will be very common, and unlike the library lookup it will tend to be more than one word long. I think being enclosed in angle brackets has a nice look.
Rebol [Title: "My Big Script"] import <common.r> import 'altxml import 'json/1.2.1 import <subsystems/gui-manager.r> import <subsystems/icon-manager.r> do/args <utils/something.r> :[1 + 2 3 + 4]
Here I'm suggesting bumping just to WORD! for loading libraries from the index, since TAG! would have this new meaning.
I'm Avoiding Types That Are Valid Branches
One of the rules I made a while ago was that if a type is accepted by a branch in a control structure, that DO should have the same behavior for that datatype.
Of course we know blocks are legal branches and do the same thing:
>> if true [1 + 2] == 3 >> do [1 + 2] == 3
But I want the rule to extend to all the other types. So in a world where
if true @json has meaning as a branch, I wouldn't want
do @json to do anything different.
So that limits the choices a bit here for this feature. Because I want you to be able to DO or LOAD things from the library of named utilities, just as you can IMPORT them.
And now with this feature of DO and LOAD relative to system.script.args, I'd like that to work as well.
Refinements Are Not Going To Be Palatable
Firstly, I'd challenge you to come up with a good name for it:
But for how common the desire is, this just doesn't look good.
Filenames Should Be Unconstrained By WORD! Rules
One might suggest reversing the suggestion I made, where you use WORD!/PATH! for the local files and keep the TAG! for the name lookups:
Rebol [Title: "My Big Script"] import 'common.r import <altxml> import <json>/v.1.2 import 'subsystems/gui-manager.r import 'subsystems/icon-manager.r do/args 'utils/something.r :[1 + 2 3 + 4]
But this gets you involved with issues about file paths not having full coverage in the domain of WORD!s. What if you want to load something and it's relative to the script directory?
smiley: load <icons/png/smiley 32x32.png>
Using TAG! for this helps avoid problems here. Whereas the name lookup service is entirely something we invent, and so constraining it to legal words makes perfect sense.
Why Not Use ISSUE! Instead of TAG! ?
This could also let TAG! stay used how it is:
Rebol [Title: "My Big Script"] import #common.r import <altxml> import <json>/v.1.2 import #subsystems/gui-manager.r import #subsystems/icon-manager.r do/args #utils/something.r :[1 + 2 3 + 4]
But I don't care for it, and I've suggested ISSUE! will be used in the import dialect for hashes.
Thoughts welcome. I know this is going to create some compatibility problems, but we can have a grace period where scripts will fall back on tags to look them up... so there will be time to fix things while still moving on with the new rules.