RFC: Forced zones

[Qix-]

Should all code be forced into a zone (namespace)? The dependency system already uses a folder structure to segregate into zones, similar to Java. However, Java allows the use of a default package, which doesn't allow any other code to reference members in the default package.

[corbin-r]

I think all code should be global and can be globally referenced by default, however. I think you should be able to define local zones (e.g, only files in the same zone can reference, access, modify).

[Qix-]

What about namespacing? Do you mean all zones are inherently global? I worry about global namespace pollution and conflicts.

[corbin-r]

Ah this is true.
Well I guess you could use both... It could be defined as your zones make all the files in the scope of that zone "local", and your namespacing could make you code accessible "outside" a zone? Or since you're doing a Java-esque dependency system, you could do away with namespaces all together and just alias zones and the files/classes/functions contained within them? (Like the Java package and import statements)

[Qix-]

I think that's essentially what was planned. However, forcing a particular filesystem seems too controlling to me. Java requires package source files to be laid out in a directory hierarchy. Further, it forces a one-class-per-file style, which in my opinion makes too many decisions on a project's structure and encourages the (mis)use of inner classes and whatnot.

However, on the flip side, if we allow zones but don't enforce a hierarchy on the filesystem, we achieve flexibility in the way projects are designed (e.g. you could use a hierarchy similar to java, or you could simply do a flat project system like C's).

In essence, I foresee the semantics looking something like:

zone MyZone
        pub fn doSomething()
                # ...

use MyZone.doSomething
# - or -
use MyZone.doSomething as doTheOnlyThing

fn main([str] args) i32
        doSomething()
        # - or -
        doTheOnlyThing()
        ret 0

However that adds an indentation level that would otherwise be pointless, especially if your files only contained one zone.

---

On the topic of forced zones (where all of your code must be in a zone), that brings up the question of entry points. main isn't necessarily the "entry point", and in the case of libraries there may not be any entry point. In Java, this is solved by allowing multiple entry points that allow the user to specify which they want to execute on the command line upon invocation.

I really like that feature of Java, but that does introduce some extra configuration - either during the build, or upon execution. Neither of those avenues seem convenient.

---

I think the topic needs to be taken back a step and really ask what should namespaces solve? There is the obvious answer - it prevents pollution and conflicts. However, when it comes to depending on other namespaces/their contents, I think there is something to be desired by some of the ways they're implemented in languages.

[corbin-r]

I think in the end result... A language that doesn't enforce hierarchy will be the one that wins. Because now it's not placing any sort of file/module layout constraints on the programmer.
However will this be any harder to compile? (doubtful but prevalent).

[Qix-]

If anything it'll make dependencies more ambiguous. Having a strict hierarchy makes things very clear as to which things should be referenced from where. Not having a hierarchy can cause ambiguity. As far as semantics go, I don't see how either of them would cause the compiler any trouble. Humans, on the other hand, are a consideration here as well.

[corbin-r]

True, either way is good (won't matter to the compiler).

[Qix-]

After working with Python a lot more I think Python's module model works very well for native code.

/
    mymodule/
        mymain.ar
    mymodule_tests/
        test.ar

mymodule/mymain.ar

use std.io

pub fn main(argv [str]) i8
    io.out("Hello, #{if argv.length > 1 then argv[2] else "world"}!")

mymodule_tests/test.ar

# just to show the flexibility of the import syntax...
from mymodule.mymain use main as main_function

pub fn test_main()
    main_function(["test"])
    main_function(["test", "Josh"])
    main_function(["test", "Sally"])