`import @json` broken under new @ rules, what now?

Development Modules
1

The IMPORT statement was using @NAME to mean "look up the module in the registry". So you could just write something like:

import @json

This was a replacement for the original syntax, of using TAG!.

import <json>

The reason tag was replaced is because as a string type, it came to be in demand for relative-to-script paths, as opposed to relative-to-current-directory paths.

So if your file is in C:\MyProject\something.reb and you do:

D:\Documents> r3 ..\MyProject\something.reb

The system doesn't change the working directory to C:\MyProject any longer (it was decided that's an undesirable behavior). So you'll still be in D:\Documents\ and so %libs/whatever.reb would be relative to that. But using TAG! lets you get the desired effect:

Rebol [File: %something.reb]
import <libs/whatever.reb>  ; relative to C:\MyProject where %something.reb lives

Strings are still used for literal source if you want to put that right inline:

import "Rebol [Title: <{my module}>] export foo: lambda [] [print <{Foo}>]"

(trying new string notation.. not that terrible...)

But Now @json Is An (Attempted-Bound) Word

We can change it so that the handling is for word, so it works... and import 'json would also work.

But then the binding is superfluous, and we should change the callsites to just use a plain tick mark.

There's nothing particularly wrong with just using a word here, but it kind of makes the import statement lose some of its... heft. It doesn't stand out as much.

We could use an issue/token:

import #json

But then we can't do tuple or path tricks and have them be actual tuples and paths.

import 'json/1.2.20  ; path with two items, second is a 3-elemnent tuple
import #json/1.2.20  ; just a utf8 string

Anyway, I guess we should just have import take WORD!, and it's not a big deal. In fact it will keep working, because since the argument to import isn't quoted we can't tell it had the @ on it. But future IMPORTs should omit the @, because it's now superfluous.

(Though actually, should @word fail if it can't bind a word? That's a question for the other thread, though...)

2

Actually, it turns out that import 'json had a meaning... it was to look for modules in a local registry vs. a remote one. @giuliolunati added this, as well as a check that during a remote import the thing you were importing remotely couldn't turn around and do a request for a local import.

Import needs either another argument or to take a block, because we can't pack all the possible desires for importation into one non-block argument. I've mentioned I don't like the idea of this being done with refinements, so either import should be arity-2 or take a block if you want to give it more arguments.

import 'json []
import 'xml [#local]

import 'json
import [xml #local]

import 'json
import ['xml #local]

I don't know, but I'm just going to make words work for now.

3

Why not plain import "json"?

4

Because:

(or if you have it in a variable, and fetched it off the network or got it from somewhere)

I also just noticed something else, which is that DO is using the same logic. (This goes back to what I was saying about DO needing to be separated from EVAL)

So if there's a script you want to run, you used to be able to say do @script but now if you say do 'script then it works... but... I don't like it.

Maybe it really is best to go for import [@json] ... something just seems off to me about import 'json

1 Like