Refactor stable modules into std

[BryantLam]

Feature request. Refactor the Chapel modules into the std namespace to prevent user-level conflicts.

There could be some interesting implications for how to handle unstable modules. Maybe something like the C++ TS namespace. Or it could be as simple as module std.unstable.SomeFeature.

[BryantLam]

Related #6698 #6979 #12711

[ben-albrecht]

The categorization of what would fall into unstable vs. stable relates to #10714 as well.

[mppf]

I'm confused about how we would do this today. Wouldn't we have to have something like C++ namespaces to even talk about doing this? (Otherwise today, we'd literally be putting all the standard modules in one file named std.chpl).

[BryantLam]

@mppf -- You're right. We couldn't.

1. Chapel doesn't have a notion of namespacing. An analogy would be how Rust separates modules and submodules (mod) from the higher-level namespace/crate. This approach would require adding a namespace feature into Chapel for e.g., support of Mason packages. duplicate module names in mason packages #8470

2. From a productivity standpoint, Should we be able to extend a module from outside the module? #10796 addresses the ability to extend a module after defining it.

3. From Rename module LinkedLists to LinkedList or List #12711, another consideration is that use LinkedLists will bring in all of its symbols into the global namespace. That remains problematic if users define their own conflicting identifiers. If users don't want to be bitten by this, then they should use only all the time, or the default for use should be set to the behavior of use only.

Edit: Added 3.

[BryantLam]

This feature request becomes possible after #13524 is resolved.

[BryantLam]

As a data point -- With an input file consisting of use FileNotFound;, I strace'd the compiler. Here's the output. You can search for "FileNotFound.chpl" and see that it is looked up in each component of the Standard module search paths.

openat(AT_FDCWD, "./FileNotFound.chpl", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "$CHPL_HOME/modules/standard/gen/linux64-x86_64-gnu/FileNotFound.chpl", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "$CHPL_HOME/modules/standard/FileNotFound.chpl", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "$CHPL_HOME/modules/packages/FileNotFound.chpl", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "$CHPL_HOME/modules/layouts/FileNotFound.chpl", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "$CHPL_HOME/modules/dists/FileNotFound.chpl", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "$CHPL_HOME/modules/dists/dims/FileNotFound.chpl", O_RDONLY) = -1 ENOENT (No such file or directory)

This behavior is one reason why I want a std namespace. With the changes in #13524, the modules/ directory can be refactored to remove almost all the openat calls.

For a non-existent module, the last five lines wouldn't appear because the compiler would know that the module indicated couldn't be in the std directory. (It's arguable whether the second line should occur either.)

Programs would then look like:

use std.Assert;
use std.Time;
use std.dists.Block;
use std.dists.Replicated;

use std.packages.BLAS;
use std.packages.UnorderedCopy;

Or something to that effect. (Hierarchy is TBD.)