import support

[xela92]

Hi, great project!

Currently, RAD scripts seem to be standalone and there is no way to reuse code or import data (e.g. JSON files).

This makes it difficult to organize larger scripts, share common utility functions and avoid copy-pasting code.

It would be great to have some import functionality.

Here's some examples of hypotetic syntax:

utils.rad

fn sum(a, b):
  return a + b

main.rad

import "./utils.rad"
import "data.json" as data

print(sum(2, 3))

x = json[].x
y = json[].y
z = json[].z

rad data:
    fields x, y, z

main.rad, alternative import syntax

import sum from "./utils.rad"

print(sum(2, 3))

Thanks for the cool project!

[amterp]

Hey @xela92!

Yes I'm on-board with this conceptually, I've been thinking about this for a while. Some thoughts:

• I generally like that all in-built functions are always available, and that scripts are very self-contained. However, this is idealistic and I recognize that, as Rad and what people want to accomplish with it grows, not having a module/import system would be a mistake.
• Scripts currently being self-contained makes them very simple to share. If we allow imports, now we need to share multiple scripts. What's a good way to try and facilitate this? Saying "download these two files and ensure they're placed relative to each other in this specific way" is a baseline option, but can we somehow do better with Rad? One idea is what I've been calling 'bundling' e.g. some way to share these things as a single file, which Rad can help you collate.
• Imports would also unlock being able to write command-based scripts across files i.e. if you have very complex commands, each command can be defined in their own file.

I generally agree with your syntax by the way. I'll need to do some more research but I don't think there's much room for improvement on what Python does, which is similar to what you wrote.

I also like your idea of importing data by the way! I can see it being potentially useful to do import "data.json" as data and Rad sees the .json extension and immediately parses it such that data is a fully parse JSON object. Though also it can go wrong -- it's nice when it works, but if it doesn't (e.g. malformed JSON), then we need to make decisions around behavior and it can maybe get a bit hairy to execute well.

FYI you can currently read data via some in-built functions, that accept relative paths. For example read_file or pick_from_resource.

[xela92]

Hi @amterp , thanks for the quick reply!

I have an idea for that: what about a Rad command to pack things together in a binary? I often see Go binaries bundled together with e.g. frontend assets using things like Embed (or, previously, Packr): the idea is to pack Rad actual binary together with all the script tree and generate a binary - the binary will just run internal rad and the main script. I also imagine a Rad's "eject" command, able to unpack the scripts from the binary, so people can edit, regenerate and redistribute the bundle.
This could also lead to improved reliability (Rad's breaking changes can't break the distributed version).

I don't know if this fits with your idea of Rad, though; another alternative could be something like Deno's http imports, e.g.

import { assertEquals } from "https://deno.land/std@0.224.0/assert/mod.ts";

with a local cache layer.

For the malformed JSON issue: the more I think about it, the more I'm convinced that import is like running a function, so it could

• handle a catch:

	data = import "file.json" catch:
	print_err("Err: malformed json")
	exit(1)

• Be a non-first-level construct:

	fn eval_json():
		data = import "file.json" catch:
			data = {}
		return data

• Not use a different syntax => data = import("file.json")

What do you think about it?

read_file is great, didn't notice that, thanks!

[amterp]

Like minds @xela92 :) I very briefly talk about this in bundling.md#executable. There's definitely something to this idea. But as I point out there, the result would probably be a little disappointing in terms of file size unfortunately. Passing 10 MB files around for simple scripts like what Rad tries to target isn't ideal haha

Making these bundled executables smaller would likely mean rewriting a Rad interpreter in another language than Go, which would be a huge lift, and forever impose additional maintenance burden as Rad continues to evolve.

The lighter version of bundling would be to have Rad somehow concatenate all your files together into one, or to zip them up and teach Rad to run these zipped versions. "Zipped" could still look like a .radb (rad bundle) file. This is kinda like in Java where .jar files are actually just zip files. But running these would of course require you to still have Rad installed.

I like the 'eject' idea, I hadn't thought of that. It helps alleviate one of my other concerns which is that packing up a Rad script into an executable presents a bit of a security risk, since it becomes obfuscated what you're running.

Also agreed with the Deno suggestion you're making, it's also similar to Go's ability to refer to Github projects as imports, which I can get behind.

re: the malformed JSON issue, what's the advantage of this over read_file and parse_json ? For example:

{"alice": "bob"

data = read_file("test.json").content.parse_json() catch:
    print_err("Failed to parse!")
    data = {}
print("Data: {data}")

❯ rad ./test.rad
Failed to parse!
Data: { }

I lean towards thinking functions being sufficient for importing data, but open to pushback.

[xela92]

Super good points!
Bash handles bundles (even with binaries) appending to the end of the file; maybe the bundle could just be the script with every imported script concatenated (or prepended)? Then Rad could take care of every "attached" script at runtime. The "eject" command then would simply create the original workspace unbundling each script.

What do you think about that?

About the JSON question, you are right: read_file does the same, so it's the correct way to handle it (and I'd stick to it). :)

[amterp]

Yep I agree that's another way to do it 👍 It does present one challenge around resolving paths at runtime. You can imagine these two statements:

import ./utils.rad
read_file("./data.json")

If we go the appended route, Rad needs to, at runtime, understand whether those two paths should be looked up in its own 'bundled script', or on the user's system. We need to make decision of what to do if both are valid lookups i.e. ./data.json exists appended in the script, and there's a file next to the script named this way. We could decide "always prefer what's bundled in the script", but it's not a clean choice and could lead to some confusion.

The zip approach avoids this issue because all the relative paths are still real paths, just in a zip archive.

Downside though is that it's slightly less transparent, but a Rad bundle command could perhaps fix this.

Anyway, I agree with importing, and it sounds like we have some possible ways to try and maintain portability across files. This is definitely on the todo list!

[Blucknote]

Hi, first of all - thanks for the project, scripting is fun again!

I have a question: does zipping introduce friction for the end user who wants to edit a shared script? I mean, the flow becomes unzip -> edit -> and then there is probably no need to zip it again?

Personally, I'm tired of infinite package managers and virtual envs

I guess git-style imports will kinda work? Scripts can be auto-updated (at the user's will) or reverted. Of course, there might be an issue if the user modifies a git-imported script locally, but I think that's manageable.

[amterp]

Thanks @Blucknote ! :)

does zipping introduce friction for the end user who wants to edit a shared script? I mean, the flow becomes unzip -> edit -> and then there is probably no need to zip it again?

Yep that's also how I'm picturing it at the moment, but I agree it's not a great flow and I'm keen to improve on that (somehow).

Personally, I'm tired of infinite package managers and virtual envs

I very much agree with this sentiment -- it's part of what motivated Rad in the first place, despite Python existing. virtual envs, etc in Python always felt onerous.

re: git-style imports, definitely a lot TBD there, I'm not sure how Rad would save and store the actual git files that are being pulled down, etc.

Keen to better understand your use case for bundling/impots, since you're concerned with this, if you're happy to share!

[Blucknote]

@amterp To be honest I don't have any real use cases. It's just projection — what if someone decided to write a database wrapper with rad or something useful and be able to use that without copy-pasting?

I also had a thought that a serverless approach of calling might fit, or be enough for PoC? I mean /path/to/script.foo — there is path, script name, function to call. But I have no idea of language design and the implications of that particular decision