Importing other files

[dfellis]

A large part of the framework for this is implemented, but need to get this over the line, and then extend it to have mocks as a first-class citizen.

I'm less sure about the verbose syntax I came up with in the RFC, though. It's a lot of grammar baked in that I'm wondering might be simplified.

[dfellis]

The first part of this: being able to add/import 3rd party Rust modules, has been implemented.

The syntax for importing Alan modules has been implemented, but has no backing, yet.

[dfellis]

To update this a bit more, since I think it'll be a bit lower priority.

What's currently implemented is:

type someType = Binds{"rust_package::RustTypeName" <- Rust{"rust_package" @ "X.Y.Z"}};
fn someFn "rust_package::rust_fn_name" <- Rust{"rust_package" @ "X.Y.Z"} :: (InputType) -> OutputType;

Breaking that down:

• "rust_package" @ "X.Y.Z" specifies the dependency name and version to import.
• Wrapping that in Rust{} indicates that this is a rust package and version, not an Alan package and version. So one feature to add is to be able to pass in an unwrapped dependency and have it grab and use the specified package. This is probably going to be the last thing implemented.
• "rust_package::RustTypeName" <- Rust{... indicates that the specified fully-qualified name for the type (or function) depends on this particular package being installed. For now it needs to be fully qualified because the second stage of the compiler doesn't generate any use statements at the top of the generated Rust file, it only makes sure that it's in the Cargo.toml [dependencies] section. This may be changed in the future for convenience, but will probably generate the same code to prevent namespace collision problems if two packages have the same type or function name.
• Therefore, something like type AlanType = "AlanType" <- "alan_pkg" @ "X.Y.Z"; should be the fully-qualified import syntax, but there is some special code right now where you can write: type AlanType <= "alan_pkg" @ "X.Y.Z"; and it will assume the type name you've written matches a type name in the package. Right now this is a separate symbol because of an operator resolution bug, but is intended to eventually be type AlanType <- "alan_pkg" @ "X.Y.Z";
• Taking this one step further, if instead of a Dependency{N, V}, you just provide a bare String as what you're importing from, that should be a basic filesystem path import, eg type AlanType <= "./alan_type.ln"; (Not sure whether or not the file extension should be in this string. Skipping it would look "nicer" but might restrict what we can do with imports.) This is probably the next piece to implement. The standard library would be accessed in a similar way, eg type Matrix <= "@std/matrix"; with the @std being a shorthand for "built-in library". We could also use the @ prefix for other purposes, like "resetting" the import to the root of the current project being built, so if you had a utils.ln file in the root, all files could import from it with "@utils.ln" or something like that.
• Taking that last point a bit further, rather than requiring a hardwired version declaration in each file that a dependency is used in, a root-level deps.ln file that declares these imports and re-exports them could be how you get your project dependencies, then just doing type MyImport <= "@deps.ln"; (or just @deps) everywhere.
• That potential overlap with @ and @std is not a mistake -- it would make it possible to disable standard library features you don't want your project to have, and explicitly injecting such things into the libraries you depend on can make sure that they don't get access to features you don't want them to. Exactly how the latter would be done requires some more consideration.