Module design about dora HOT 4 CLOSED

LGTM, I have some questions to clarify:

• So a file say x/y/z1.dora could be in package foo::bar, while x/y/z2.dora might be in package some::other? Modules are completely distinct from the file structure? Not saying this has to be the case, but we could think about something like this. E.g. module some; includes all *.dora-files in the directory some.
• How would you invoke Dora with multiple source files. Right now Dora can be started with either exactly one input file or directory. When we need multiple input files we probably need changes to the command line parser and use -- to separate input files from the arguments to the Dora program.

from dora.

Forgot this: I guess we should then also discuss how we want to include libraries into Dora

from dora.

So a file say x/y/z1.dora could be in package foo::bar, while x/y/z2.dora might be in package some::other? Modules are completely distinct from the file structure? Not saying this has to be the case, but we could think about something like this. E.g. module some; includes all *.dora-files in the directory some.

I think what's important for me is that one can use a single folder with various files with potentially different module declarations. It might make sense to support both, a flat hierarchy for small things like scripts and a full blown hierarchy where the folder structure follows the module declarations (and the compiler would warn if a file was incorrectly placed somewhere else).

But that's coming from the perspective of someone who finds Rust's approach rather unintuitive and confusing. :-)

How would you invoke Dora with multiple source files. Right now Dora can be started with either exactly one input file or directory. When we need multiple input files we probably need changes to the command line parser and use -- to separate input files from the arguments to the Dora program.

I guess we should then also discuss how we want to include libraries into Dora

I imagine that every library would consist of either flat files or a directory hierarchy combined with a metadata file that defines the name, author, version, dependencies and so on. Now put those things into a tar or zip file.

I propose calling such an archive a crate (for the lack of a better name).

Depending on code in Dora would work on the level of those crates. You could distribute those archives and refer to them by the crate name.

So you could say dora --crate my.module and Dora would resolve the dependencies specified in your metadata file of your crate my.module and run your crate.

One important thing here is that dependencies should not be transitive: If crate B depended on crate A, and crate C would depend on crate B, it wouldn't get crate A "for free", it would need to explicitly depend on it.

I would probably push this so far that dora would be distributed as a single binary, without even the standard library, which would be a crate like every other library. This means the standard library crate could be updated on its own, and it would keep us honest in terms of not having a dependency mess inside our core libraries.

from dora.

This is resolved/outdated.

from dora.