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

List built-in library names #2

Open
lassik opened this issue Apr 29, 2019 · 15 comments
Open

List built-in library names #2

lassik opened this issue Apr 29, 2019 · 15 comments

Comments

@lassik
Copy link
Member

lassik commented Apr 29, 2019

From #1:

The R6RS vs R7RS case could be solved by listing the built-in library names instead of just the SRFIs. That would also be more generally useful, I think, because there's also a bunch of code that is shipped as libraries in implementations (e.g. IronScheme and Sagittarius) that should be more widely available.

@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

(import
  (rnrs (6))
  (srfi :123))

whereas R7RS has

(import
  (scheme base)  ; etc.
  (srfi 123))

Do these differences have ramifications here?

@weinholt
Copy link

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.

@lassik
Copy link
Member Author

lassik commented Apr 29, 2019

If we limit the listing to libraries that can be loaded from R6RS/R7RS code

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)?

@weinholt
Copy link

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.

@lassik
Copy link
Member Author

lassik commented Apr 29, 2019

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?

@weinholt
Copy link

Yes, I think that would be best.

@lassik
Copy link
Member Author

lassik commented Apr 29, 2019

Great. Would a syntax like the following be ok?

(release
 (date (2017 8 6))
 (version-number "1.3")
 (bundled-library
  (name (srfi 19))
  (name (srfi :19)))
 (bundled-library
  (name (srfi 27))
  (name (srfi :27))))

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 (name ...) forms could be used to give aliases to the same underlying library, as here.

@FrankRuben
Copy link
Contributor

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

@lassik
Copy link
Member Author

lassik commented May 1, 2019

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 (library ...) or R7RS (define-library ...) form, whereas one package can contain multiple libraries). Also AFAICT libraries don't have their own version numbers independent of the Scheme they ship with. They may have their own licenses if the implementor got them from some other project.

@lassik
Copy link
Member Author

lassik commented May 1, 2019

(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".)

@lassik
Copy link
Member Author

lassik commented May 1, 2019

The (bundled-library (name ...)) syntax is looking super-verbose here. I'll change it to just library which is equally clear since it's inside the (release ...) form (i.e. a library in a release).

@lassik
Copy link
Member Author

lassik commented May 1, 2019

@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 : prefixes for the numbers) those implementations use. Unless you hate the current (library ...) syntax in which case let's discuss alternatives.

@lassik
Copy link
Member Author

lassik commented May 1, 2019

"module" is the Racket term for Scheme's "library"

Just found out Guile also has something called "modules". You can write (use-modules (srfi srfi-9)) but (import (srfi :9)) works also. Are there other Schemes that have their own module system separate of R6RS and R7RS libraries?

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)?

@weinholt
Copy link

weinholt commented May 1, 2019

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.

weinholt pushed a commit that referenced this issue May 2, 2019
@lassik
Copy link
Member Author

lassik commented May 3, 2019

Thank you :)

The libraries are not in sorted order; is the current order significant for some task?

@weinholt
Copy link

weinholt commented May 3, 2019

No, the library order is not significant.

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

No branches or pull requests

3 participants