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

Development Modules
4

We'll need to find a way to get everything everyone wants to do in the syntax. What makes this hard is that with the rule that DO must act as any branch would, then DO has so many meanings for types already. :-/

It makes it tempting to get some other word in there. Of course, there's LOAD.

do load @json
do load 'json

That's fairly succinct. And it could then mean that do @json and do 'json could have different behavior more mechanically related to branches.

Earl said a long time ago that he thought DO was too overloaded. I think he wanted the basic DO to just run BLOCK!s and to have all the other mechanics pulled out to something else.

It's a bit of a loss to not have the syntax of just do <tool>...and if we went full in on the idea then it would mean we'd lose do %file.r too. :frowning:

It could be another word, like run %file.r and run <tool>. Maybe RUN could also be variadic, and take a number of args that the tool would take on the command line.

$ r3 some-script.r arg1 arg2

>> run %some-script.r arg1 arg2

This could take the pressure off DO for its argument types, allowing it to 100% match how branches act, and always be running on already-LOAD-ed data.

Then RUN + LOAD + IMPORT could share a concept of how they interpret types to locate source.

:question:

If this all aligns, then I don't yet have a strong opinion on:

import 'local-module
import @json

import @local-module
import 'json

Either would work. But there is also the bigger question of IMPORT syntax for when it has more options...that needs to be thought through.

import [
    @json
    /version 1.2.1  ; syntax for fields, to save reserved-words?
    parse-json  ; just import a thing by name?
    jget: get-json  ; be able to rename an import?
]

I thought this looked kind of crappy and asked for instance if we might be able to "sniff" blocks variadically in the import statement:

import @json [
    /version 1.2.1  ; syntax for fields, to save reserved-words?
    parse-json  ; just import a thing by name?
    jget: get-json  ; be able to rename an import?
]

And maybe even do more with sensing. I feel like noticing SET-WORD! on the left to give a name to the import is sort of a non-negotiable thing:

j: import @json

But it makes import a little harder for people to adapt import, the weirder and more "sensing" it gets. It's probably worth it.

Here's what I said about contrast with JavaScript import

Lots of unanswered questions! But, maybe this RUN idea can help untie our hands. Or maybe it's backwards...and DO should remain the version for running files, and some other function is needed for evaluating values as branch-types...