-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Importing SRFIs through (srfi nnn)
instead of (std srfi nnn)
#596
Milestone
Comments
We could create stubs that map srfi to std/srfi with re-exports; we would accept a pr doing so. |
So for v0.18, we will make shims that reexport |
It is still an open invitation if you want to make a pr for this, as it is in the bottom of the backlog for v0.18 |
#829 adds the necessary shims. |
vyzo
added a commit
that referenced
this issue
Sep 12, 2023
vyzo
added a commit
that referenced
this issue
Sep 13, 2023
* Build top-level SRFI shim modules Closes #596 * srfi cpackages: 146, 159, 160
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#gerbil-scheme
on Freenode, 28 Feb. 2020 (summarized):Since then I’ve come across the following:
SRFI 135 explicitly says:
SRFI 136 refers to this convention as if a standard:
SRFI 211 (admittedly still in the draft stage as of writing) exports various sublibraries of
(srfi 211)
(like(srfi 211 low-level)
,(srfi 211 explicit-renaming)
, etc.)As this seems to be not only a de facto standard but also de jure acknowledged by a few SRFIs, could Gerbil allow these names for SRFIs too? Until R7RS gives names to certain SRFIs, this is the only way to write halfway portable programs using them.
The text was updated successfully, but these errors were encountered: