We Need A Syntax For "IMPORT Relative To System.Script.Path"

Development Modules
10

I'm reaching the critical mass where I think I am likely to move to your suggestion of angle bracket URL!s... but in a sense you may or may not like, which is to eliminate the lexical URL! type entirely.

Hence URL! would shift to being some kind of structured object type that you could create from TAG! or TEXT!... or even PATH!.

This gives us the full spectrum of PATH!, CHAIN!, and TUPLE!. I'm not sure what we'll do with things like:

///foo/_.?:/bar:++/9

But I'm sure I'll think of something. Being able to add a slash in front of things is nice, being able to add two slashes could be nice too.

/foo

//foo

///foo

Anyway...

I Could Accept URL/URI-like-things For Library Modules

They'd be TAG!s.

But the original question comes up...

We Need A Syntax For “IMPORT Relative To System.Script.Path"

This could be done with a syntax also using tags, like:

<./script1.reb>
<./subdir/script2.reb>

A problem here is that a construct which wished to do the "relative to the current module" magic like IMPORT would be a bit stuck... since if you get a TAG! it's just a string and you don't have the knowledge that the import command does.

import <./script1.reb>
source-code: read <./script1.reb>  ; READ doesn't know what IMPORT does

The Slippery Slope To Binding Strings...

The mechanics of Ren-C are such now that we do have concrete answers for how something like a TAG! could carry context and be bound at its point of evaluation.

Not only bound at the point of evaluation, but carry its "definitional binding" along with it when it's picked out of "inert"-looking blocks, because the contexts travel with it.

You could explicitly leave tags unbound with '<./script1.reb>.

So we really could have tags carry their binding with them, in such a way that <./script1.reb> could be translated (by some generic mechanism that knew to care) into using something like this-script.directory.

Whether this is a good idea or not, I feel kind of like I should do a draft implementation so if it's terrible I at least understand the terrible reasons not to do it.

I've found a few occasions lately where trying to write long posts has been diminishing returns on things that I've thought about for a long time, when trying can be done in a matter of a few hours. So maybe I'll look into this and see what kinds of things come up.

1 Like