Module syntax

[LighghtEeloo]

As the standard library continues to expand, it becomes essential to introduce a namespace system to better manage and organize the growing codebase. We propose implementing a lightweight module system, coupled with the name resolution phase, to address the issues of increasingly long variable names and parsing time.

Notice that the word "module" here is abused - we have no intension in achieving modularity in any sense. Our module system will primarily focus on namespace management and will serve as syntactic sugar for fully qualified names, rather than being a first-class term. This design aims to streamline the code organization without adding unnecessary complexity.

The ability to export a symbol table from a module will be reserved for future enhancements in the language. These improvements will be closely tied to the semantics of visibility control using the pub keyword.

The principles and goals for this design have been outlined above. Concrete design choices and implementation details will be left to @SchwarzXia to determine and document as the development progresses.

[SchwarzXia]

Here's a list of tentative new syntaxes that I think we should add in this first stage:

1. module <name> ... end: Defining a module. Every definition, say <var>, inside will be named as <name>.<var> outside of module. Submodules are supported by nesting module definitions.
2. open <module>;. Opens a module and introduces the contents in the module so that the user can refer to them directly by name without module name. Effective till the end of the scope open is in. See #12 for name conflict/ambiguity issues.
3. open <module> using <name>,...;. A variant on open that only introduces names the user specified. This is useful for users to avoid name conflict issues, especially on large modules like std.
4. import <filename>. This allows for multi-file programs. Definitions in another file would need to be imported first before being able to be used. import should only appear on the outer most scope and would import the files in the given order. At current, we can assume that all user code files are in one flat directory, and that the standard library is in one file and is always imported (unless we really need to separate that into multiple files). We would need to do some sort of circular dependency/duplicate import checking.