Revamping the import system

Each feature here could be presented as an independant proposal, but since they all center around the same system, it makes sense to present them as one.

Every module is available without an explicit import

Just as it says on the tin. If you don't need to specify an alias or import things unqualified, then you don't need an import statement at all. This should greatly reduce the need for imports, and encourage using qualified references.

No more default imports

The recent operators as syntax sugar proposal would benefit from being able to choose which function is called when an operator is used. This doesn't work too well with default imports.

Making every module available without explicit import statements helps somewhat, but there are certain values that would be nice to have imported by default, like Just and Nothing.

To help with this, the CLI will get a generate command which can generate a new module with a specific set of imports included in the template. This way, the default imports are explicit, and can be removed or changed according to the whims of the programmer.

A from keyword

We don't really have a good way of dealing with collisions in module names. This proposal simply adds a from keyword that can be used to select which package a module should be imported from, as a way to select a winner between colliding modules.

import MyModule from "skinney/package"
import MyOtherModule from "application"

Move documentation comment above module declaration

This will be more inline with how documentation comments work in all other parts of the language, and also avoid ambuguity when the import section is empty (which is more likely if the above proposals make it into the language).

Other than moving the location of the documentation comment, no other changes are made to the module's documentation comment.

Dissallow modules sharing a name or alias

Gren currently allows two modules to share a name (common example is aliasing Array.Extra as Array, to merge those two namespaces). This makes it hard to tell where a function really resides, especially when the import section isn't available (diffs or tutorials). It can also make it harder for external tools to know where a value comes from.

Suggestion removing this ability.

Start by separating the import-system proposals in this issue and tracing the compiler's existing module/import handling and CLI entry points. Resolve the scope and design for implicit modules, default imports, the from syntax, documentation-comment placement, name collisions, and the proposed generate command before implementation; done requires an agreed proposal for each part.