Description
What it is
These are just *.rickroll
files that the interpreter can conditionally embed into userland *.rickroll
files. They are assigned to a special namespace, which the interpreter/compiler knows exactly where to locate unambiguously.
What it ISN'T
This isn't a generalized module system, as there's no support for userland scripts. This shall be implemented in a separate proposal (#75), for simplicity's sake.
Why
- Portability
- RR programs would no longer need 3rd-party lang-specific libraries, so they can work exactly the same on any implementation.
- Abstraction
- Everything is self-contained.
- Fun!
- We'll have freedom to name modules however we want! Example:
core.math.pie
is the π constant from themath
module.
- We'll have freedom to name modules however we want! Example:
How
The implementation details are yet to be stabilized. I have a rough idea of how we could do it: RR modules would be inlined in a C-like manner, which is quite simple, but not perfect.
The reason behind a "special namespace" for built-in modules, is to simplify the module-resolution algorithm for when we add support for userland RR libs:
- Userland libs would be imported using file-system path-string-literals, such as
we know the "./FILE_NAME" and we're gonna play it
(notice how the extension is optional) - Built-ins would be imported using similar (maybe exactly the same?) syntax as
we know the std.MOD_NAME and we're gonna play it
(notice the prefix to disambiguate between C/Py and built-in)
We could take inspiration from Rust by having different namespace-prefixes:
core
- for self-contained stuff, such as
- math processing
- string formatting
- list iteration and sorting
- etc...
- for self-contained stuff, such as
std
- for abstractions over platform-specific and impl-specific code, such as
- file handling
- network communication
- threads (and possibly
async
(Proposition for key words #32)?) - etc...
- for abstractions over platform-specific and impl-specific code, such as
std
would CONSIDERABLY reduce the need for importing Py libs/mods such as sys
and os
Outro
I'm willing to contribute modules. We could even use stuff from the examples
folder as a starting point. Even better, core
/std
could become examples themselves!