Skip to content
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

Closed
dpk opened this issue Feb 18, 2021 · 4 comments · Fixed by #829
Closed

Importing SRFIs through (srfi nnn) instead of (std srfi nnn) #596

dpk opened this issue Feb 18, 2021 · 4 comments · Fixed by #829

Comments

@dpk
Copy link
Contributor

dpk commented Feb 18, 2021

#gerbil-scheme on Freenode, 28 Feb. 2020 (summarized):

[16:38:03] <dpk> as far as i know the standard is that it should be (import (srfi nnn))
[16:38:14] <dpk> but Gerbil seems to require (import (std srfi nnn))
[16:38:42] <dpk> i'm not sure why i think that's the standard, other than that i'm fairly certain i've seen it mentioned in SRFIs and also Chibi Scheme uses it
[16:38:58] <dpk> why does Gerbil do it differently, and shouldn't it follow the standard?
[16:39:22] <belmarca> seems like the standard is (import (scheme list))
[17:38:23] <vyzo> yeah, the standard paths are prefixed by scheme and are all supported
[17:38:27] <vyzo> the others go to stdlib
[17:38:32] <vyzo> i am not inclined to change that

Since then I’ve come across the following:

  • SRFI 135 explicitly says:

    The procedures specified by this SRFI are exported by the (srfi 135) library. In R6RS systems that do not yet support R7RS library names, the name of this library is (srfi :135).

  • SRFI 136 refers to this convention as if a standard:

    the keyword define-record-type defined in this specification can serve as the equally named keyword from SRFI 9 and R7RS and can thus be safely exported from (srfi 9) and (scheme base)

  • 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.

@vyzo
Copy link
Collaborator

vyzo commented Feb 18, 2021

We could create stubs that map srfi to std/srfi with re-exports; we would accept a pr doing so.

@vyzo
Copy link
Collaborator

vyzo commented Sep 9, 2023

So for v0.18, we will make shims that reexport srfi -> std/srfi; this should solve the problem.

@vyzo
Copy link
Collaborator

vyzo commented Sep 9, 2023

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

@vyzo vyzo added this to the Gerbil18 milestone Sep 9, 2023
vyzo added a commit that referenced this issue Sep 12, 2023
@vyzo
Copy link
Collaborator

vyzo commented Sep 12, 2023

#829 adds the necessary shims.

vyzo added a commit that referenced this issue Sep 12, 2023
@vyzo vyzo closed this as completed in #829 Sep 13, 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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants