You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
I have read all your issues, and I think your proposal is amazing. I haven’t worked on this for a long time, and I am ready to accept the challenge to rewrite in Rust 👍
I will start building a standard library, and thank you for all these issues!
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
core.math.pie
is the π constant from themath
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:
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:
core
std
async
(Proposition for key words #32)?)std
would CONSIDERABLY reduce the need for importing Py libs/mods such assys
andos
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!The text was updated successfully, but these errors were encountered: