RnRS module system tutorial

[godek....@gmail.com]

Hi,
I've been using Guile's module system for a long time now,
but recently I needed some more portability and tried to employ
the RnRS module system.

However there seems to be a bit of mess in there.
R6RS uses the "library" form for defining modules.
R7RS uses "define-library" form for this, and I have
also seen a "module" form used somewhere.

Is there such a thing as an "official module system syntax for Scheme"?
How widely is it supported?
Are R6RS and R7RS module systems compatible with each other?
Are there any tutorials on this?

Cheers

[Takashi Kato]

On Saturday, October 28, 2017 at 8:00:43 PM UTC+2, godek....@gmail.com wrote:

> Is there such a thing as an "official module system syntax for Scheme"?

Yes, R6RS and R7RS as you mentioned.

> How widely is it supported?

For R6RS: http://www.r6rs.org/implementations.html
For R7RS: https://bitbucket.org/cowan/r7rs-wg1-infra/src/95f082ee805bb0355ad0cca1b1835fed9a75b78d/ImplementationSupport.md?at=default&fileviewer=file-view-default

(R7RS wiki seems gone so the repository of it)

> Are R6RS and R7RS module systems compatible with each other?

No, but it should be relatively easy to write compatible layer.

NB: Larceny and Sagittarius support both R6RS and R7RS so could be
an option to use.

> Are there any tutorials on this?

If you meant syntax wise, then you can find variety of examples on Github.

[godek....@gmail.com]

W dniu wtorek, 31 października 2017 13:32:05 UTC+1 użytkownik Takashi Kato napisał:
> On Saturday, October 28, 2017 at 8:00:43 PM UTC+2, godek....@gmail.com wrote:
>
> > Is there such a thing as an "official module system syntax for Scheme"?
> Yes, R6RS and R7RS as you mentioned.

I did use the singular form on purpose, though ;)

> > How widely is it supported?
> For R6RS: http://www.r6rs.org/implementations.html
> For R7RS: https://bitbucket.org/cowan/r7rs-wg1-infra/src/95f082ee805bb0355ad0cca1b1835fed9a75b78d/ImplementationSupport.md?at=default&fileviewer=file-view-default

Thanks!

> > Are R6RS and R7RS module systems compatible with each other?
> No, but it should be relatively easy to write compatible layer.

Hmm. Do you (or somebody else) know if there was a particular reason
why someone decided that it is a good idea to make R7RS module system
incompatible with R6?

> NB: Larceny and Sagittarius support both R6RS and R7RS so could be
> an option to use.

Actually my intent was to make some of my modules portable,
but now I'm not sure if that's even possible

> > Are there any tutorials on this?
> If you meant syntax wise, then you can find variety of examples on Github.

Thanks!

[Takashi Kato]

On Wednesday, November 1, 2017 at 8:32:59 AM UTC+1, godek....@gmail.com wrote:
> I did use the singular form on purpose, though ;)

Oops, then depending on which specification you want to follow :)

> Hmm. Do you (or somebody else) know if there was a particular reason
> why someone decided that it is a good idea to make R7RS module system
> incompatible with R6?

One of the reason why define-library was chosen could be this:
https://groups.google.com/forum/#!searchin/scheme-reports-wg1/define-library/scheme-reports-wg1/S5mEL_6dX3Q/w3kgQhSOUAEJ

But I don't exactly know why it has to be differ from R6RS.

> Actually my intent was to make some of my modules portable,
> but now I'm not sure if that's even possible

The only way I can think of is that using some sort of pre-installation scripts.
But it'd be indeed pretty rough to do.

Cheers,

[jco...@precisionhealth.ai]

On Wednesday, November 1, 2017 at 3:32:59 AM UTC-4, godek....@gmail.com wrote:

> Hmm. Do you (or somebody else) know if there was a particular reason
> why someone decided that it is a good idea to make R7RS module system
> incompatible with R6?

The two systems are broadly compatible conceptually: they both have libraries, exports, imports (including selective imports). But whereas an R6RS library is just(library <name> (export <identifier> ...) (import <import-specs>) <scheme-forms>), an R7RS library is written in a separate language which is not Scheme, though the (begin ...) form contains Scheme code. I thought it was a Good Thing that it be easy to tell one kind of library from another right off the top.

I don't remember if anyone expected hybrid R6RS/R7RS systems like Sagittarius and Larceny back then.

--
John Cowan http://vrici.lojban.org/~cowan co...@ccil.org
We are lost, lost. No name, no business, no Precious, nothing. Only empty.
Only hungry: yes, we are hungry. A few little fishes, nassty bony little
fishes, for a poor creature, and they say death. So wise they are; so just,
so very just. --Gollum

[Chris Vine]

On Tue, 27 Feb 2018 06:55:53 -0800 (PST)
jco...@precisionhealth.ai wrote:
> On Wednesday, November 1, 2017 at 3:32:59 AM UTC-4,
> godek....@gmail.com wrote:
>
> > Hmm. Do you (or somebody else) know if there was a particular reason
> > why someone decided that it is a good idea to make R7RS module
> > system incompatible with R6?
>
> The two systems are broadly compatible conceptually: they both have
> libraries, exports, imports (including selective imports). But
> whereas an R6RS library is just(library <name> (export
> <identifier> ...) (import <import-specs>) <scheme-forms>), an R7RS
> library is written in a separate language which is not Scheme, though
> the (begin ...) form contains Scheme code. I thought it was a Good
> Thing that it be easy to tell one kind of library from another right
> off the top.
>
> I don't remember if anyone expected hybrid R6RS/R7RS systems like
> Sagittarius and Larceny back then.

But just what was wrong with the R6RS library specification that
required Yet Another Incompatible Library Implementation?

Some of the changes made in R7RS seem to be have been made just to be
gratuitously different. R6RS records and hashtables may not have been
ideal but at least they were there.

[jco...@precisionhealth.ai]

On Tuesday, February 27, 2018 at 1:43:19 PM UTC-5, Chris Vine wrote:

> But just what was wrong with the R6RS library specification that
> required Yet Another Incompatible Library Implementation?

It's inextensible, basically.

> Some of the changes made in R7RS seem to be have been made just to be
> gratuitously different. R6RS records and hashtables may not have been
> ideal but at least they were there.

The opposite might well be said: R6RS was gratuitously incompatible
with SRFI 1 (lists), SRFI 9 (records), and SRFI 69 (hashtables). The
Red Edition of R7RS-large is based firmly on those SRFIs.

--
John Cowan http://vrici.lojban.org/~cowan co...@ccil.org

You're a brave man! Go and break through the lines, and remember while
you're out there risking life and limb through shot and shell,
we'll be in here thinking what a sucker you are! --Rufus T. Firefly

[godek....@gmail.com]

W dniu sobota, 17 marca 2018 06:36:35 UTC+1 użytkownik jco...@precisionhealth.ai napisał:
> On Tuesday, February 27, 2018 at 1:43:19 PM UTC-5, Chris Vine wrote:
>
> > But just what was wrong with the R6RS library specification that
> > required Yet Another Incompatible Library Implementation?
>
> It's inextensible, basically.

What do you mean by that?
Could you give an example of R6RS module system being inextensible?
How is it solved in R7RS?

[Yuki Okumura]

2018年2月27日火曜日 23時55分56秒 UTC+9 jco...@precisionhealth.ai:
- snip -

> I don't remember if anyone expected hybrid R6RS/R7RS systems like Sagittarius and Larceny back then.

One of Ballot3 #83 purpose was allowing such implementation.

https://bitbucket.org/cowan/r7rs-wg1-infra/src/5f7390296a330243cee403667ab6ec2a2ff22d4f/WG1Ballot3Shinn.md

"Leaving keywords unbound allows multiple unrelated macros to use the same
keywords, but Chez breaks in this case. Fortunately, for the keywords used in
the standard, all macros can refer to the same bindings, so I recommend we
bind them and perhaps recommend third-party modules to not bind their keywords."

In case you'd needed to import both R6RS and R7RS libraries which would use the same(-named) aux-keyword, their bindings required to be consistent.

Unfortunately, even for standard aux-keywords, some implementations do not bind them in its standard library:

https://github.com/okuoku/yuni/blob/b73c8eb2762a2a7029fbe2221d4435c7c09e306b/doc/sibr/SIBR0001-AUX-KEYWORDS.md

So my library(for R6RS/R7RS) choose to generate "stub library" for each supported implementation

https://github.com/okuoku/yuni/blob/127a7005ab1047ef16974dda75f12fcb95726295/doc/PortingNotes/StubLibrary.md

(and, stub libraries are used to normalize other incompatibilities for example "define-library" and "library" forms :)