-
Notifications
You must be signed in to change notification settings - Fork 3
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
List built-in library names #2
Comments
I don't think these differences are significant. They are pretty mild compared to some native module systems. If we limit the listing to libraries that can be loaded from R6RS/R7RS code then just listing the names like they appear in your examples is fine. |
Do you mean having two separate listings, one for R6RS and the other for R7RS? Or having one listing containing only names that can be imported from both R6RS and R7RS code (and names importable from only one of those would be omitted from the list)? |
I think it's enough with one listing containing all available libraries. With built-in libraries the Schemes usually make it possible to load them from both R6RS and R7RS code. That's even the case for Larceny's R7RS-only SRFIs, AFAICT, they can be loaded from R6RS code if the R7RS library name is used. It just isn't available under the "right" R6RS name. |
That seems reasonable. If an implementation makes a particular SRFI available under both the official R6RS-style and R7RS-style names, would we just include both of those names in the list? |
Yes, I think that would be best. |
Great. Would a syntax like the following be ok?
It's a bit verbose but I would prefer the extensibility since it would be nice to have the option to write down some details about the libraries later on. Multiple |
you could also check the package definition format used by GNU Guix, as (something like) a package manager it also needs to define a DSL for software version info, check e.g. here |
That looks good. I added it to the package metadata samples in the wiki. However, libraries bundled with a Scheme implementation are somewhat different from packages. (A library roughly corresponds to a R6RS |
(I agree that the terminology is confusing. Package, collection, library, module. Most people would think these are synonyms but AFAICT "module" is the Racket term for Scheme's "library", "collection" is Racket's own term that doesn't have an equivalent in Scheme, and "package" is what both Scheme and Racket use for "something that ships in a tar file and you install from the package manager".) |
The |
@weinholt As an example, can you fill in the library names for Ikarus and/or Ypsilon using the current syntax (unless you hate it :p) using whatever import names (with and/or without |
Just found out Guile also has something called "modules". You can write How should we deal with the module-vs-library distinction in our metadata? Are all modules usable as libraries and vice versa (perhaps with some minor details different)? |
Turns out it would be good to have this type of data in r6lint, so I will go and fetch something for Ikarus. A lot of Schemes have "modules", including Chez Scheme and Ikarus. From what I have seen the native module systems interoperate with R6RS code just fine. |
Thank you :) The libraries are not in sorted order; is the current order significant for some task? |
No, the library order is not significant. |
From #1:
@weinholt Would you like to suggest a format for this list? You have a good background for drafting it since you've been wrestling with these issues in Akku.
It seems R6RS uses
whereas R7RS has
Do these differences have ramifications here?
The text was updated successfully, but these errors were encountered: