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 the math module.
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...
std
- 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!
What it is
These are just
*.rickrollfiles that the interpreter can conditionally embed into userland*.rickrollfiles. 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
core.math.pieis the π constant from themathmodule.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:
we know the "./FILE_NAME" and we're gonna play it(notice how the extension is optional)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:
corestdasync(Proposition for key words #32)?)stdwould CONSIDERABLY reduce the need for importing Py libs/mods such assysandosOutro
I'm willing to contribute modules. We could even use stuff from the
examplesfolder as a starting point. Even better,core/stdcould become examples themselves!