I'm worried

30 views
Skip to first unread message

Vincent Manis

unread,
Mar 8, 2022, 6:52:13 PMMar 8
to scheme-re...@googlegroups.com
The recent threads regarding R7RS-Medium and related topics have really
disturbed me. Regardless of the merits of such a project, I am concerned
about the further dilution of our efforts; our community is not large
enough to support a multiverse of standardization projects. Furthermore,
R7RS-Medium is at present a name without a clear target (which is to
some extent my criticism of R7RS-Large, as well) or any clear
organization or process in its development.

Now “Scheme” is not a trademark, and any person or persons can create
any Scheme standard they like, and it's not for me to say whether or not
people should do that. But I would like to see whatever work be
constructive, rather than working at cross-purposes.

Accordingly, if R7RS-Medium is something that is actually going to
happen, I would like to see the following.

    - the names of the persons who are committing to be editors of the
resulting Report, including at least some of the individuals responsible
for the leading Scheme implementations

    - the relationship between the proposed Report and R7RS-small
(i.e., a list of cases of “it is an error” and “unspecified” that Medium
will tighten)

    - the process by which the Medium committee will work with the
Large effort

    - a list of the functionality from R6RS that is proposed for the Report

    - a decision rule (a predicate, if you like) that distinguishes
libraries to be included in the Report from those not to be included,
perhaps intended for Large.

These five points would be stated in a charter for this group, along
with an action plan.

If this is done properly, then Medium can be a step on the way to Large.
If not, then I fear that the whole process of turning out a
specification for a Scheme that is practical for serious problems will
result in a further dilution of our efforts and increased factionalization.

Further, I would like to suggest that the time for expansive
philosophical discussion has come and gone; the field of programming
language standardization is over 60 years old (dating from ALGOL 60 and
COBOL-61), and we should be able to focus on a program of action.

Finally, I note that John Cowan has been fairly silent on this topic. I
would really like to hear his thoughts.

-- vincent


Daphne Preston-Kendal

unread,
Mar 9, 2022, 2:39:23 AMMar 9
to scheme-re...@googlegroups.com
On 9 Mar 2022, at 00:52, Vincent Manis <vman...@gmail.com> wrote:

> Accordingly, if R7RS-Medium is something that is actually going to happen, I would like to see the following.
>
> - the names of the persons who are committing to be editors of the resulting Report, including at least some of the individuals responsible for the leading Scheme implementations
>
> - the relationship between the proposed Report and R7RS-small (i.e., a list of cases of “it is an error” and “unspecified” that Medium will tighten)
>
> - the process by which the Medium committee will work with the Large effort
>
> - a list of the functionality from R6RS that is proposed for the Report

All of these are still to be decided. Marc provisionally volunteered to be editor for a Medium spec, depending what comes out of the process to decide an agenda; I have volunteered to assist (which I envision will largely consist of facilitating co-ordination between the WG2 chair and Medium spec editor, as well as proof-reading and similar organizational/secretarial tasks).

I don’t think we can know what specific behaviours Medium will ultimately tighten — we will have to consider all of them and how they interact with one another and with other requirements.

I join your concern about cooperation between Medium and Large. It depends how those who have less interest in the Medium effort want to proceed. One way would be to delay further ballots on Large until Medium is done: this would not preclude further Large work, but keep it within the SRFI process until Medium is done. (However, once Medium was done, there would already be a larger number of things, currently at the pre-SRFI stage, which would be fully SRFI’d with specs and sample implementations, ready to vote in straight away.) Another option would be to work completely in parallel, with further ballots on Large libraries continuing while Medium defines the technical basis for them (this may sound odd, but considering the likely level of compatibility between small and Medium, and as Large has thus far been working on the basis of small alone, it’s not really significantly odder than the current situation). In either case, decisions made by Medium can significantly simplify the ‘Ultraviolet’ process of cleaning up the adopted SRFIs for Large into a single, coherent Large spec, allowing the SRFI-based process to continue more or less as it is, with the underpinning of Medium providing a greater guarantee that the end product of Large is a self-consistent programming language.

Likewise, what parts of R6RS we want to adopt is, I think, a question we will have to decide as we go along — crucially, as several people have noted, we need to know what implementers are willing to swallow (especially ones that rejected R6RS before now).

> - a decision rule (a predicate, if you like) that distinguishes libraries to be included in the Report from those not to be included, perhaps intended for Large.

A rough consensus seems to be:

(define (eligible-for-medium? feature)
(not (or (r7rs-small-portable? feature)
(r7rs-small+ffi-implementable? feature))))

> These five points would be stated in a charter for this group, along with an action plan.

To set out clear goals like this was a goal of my initial draft ‘roadmap’ posted on Monday evening. If the response from chair and/or steering committee is positive, I hope we can move forward and work together to turn that draft into a firm, agreed agenda.


Daphne

Lassi Kortela

unread,
Mar 9, 2022, 2:47:32 AMMar 9
to scheme-re...@googlegroups.com
> Accordingly, if R7RS-Medium is something that is actually going to
> happen, I would like to see the following.

Agreed on all.

Simple proposal:

- R7RS shall be only R7RS-small.

- The new "medium" language shall be called R8RS, and shall contain
everything in R6RS and R7RS as optional modules. Otherwise, ask
implementers what they're willing to put up with.

- The new "large" language shall be R8RS + the large libraries on top.

You'd still be hitting the following problems:

- Libraries are by their nature loosely coupled to the core language.

- The library effort intrinsically moves at a different pace than the
core effort.

- The library effort easily slows down the core effort if they're coupled.

All three have a common cause: There's little reason to tie the
libraries to any given edition of the core language.

Currently it seems that for libs the only core language question is
whether keyword arguments are available or not.

Dr. Arne Babenhauserheide

unread,
Mar 9, 2022, 4:07:46 AMMar 9
to scheme-re...@googlegroups.com, Lassi Kortela

Lassi Kortela <la...@lassi.io> writes:

>> Accordingly, if R7RS-Medium is something that is actually going to
>> happen, I would like to see the following.
>
> - The new "medium" language shall be called R8RS, and shall contain
> everything in R6RS and R7RS as optional modules. Otherwise, ask
> implementers what they're willing to put up with.

Why "everything … optional"?

If I understand this correctly, it would make programs written for R8RS
much harder to re-use in another R8RS Scheme.

It would neither be a superset, nor a subset, but more like a sponge.

> All three have a common cause: There's little reason to tie the
> libraries to any given edition of the core language.

With many optional modules, this would make compatibility of the
libraries with a given Scheme that has a random set of optional modules
pretty hard.

Either you could not use any core feature from the core language, or
you’d have to check for each library individually whether you can use
it.


As a use-case:

Alice wants to write an estimation for implementing a web and desktop
GUI to control a micro-controller using a new networking protocol. She
gives Bob the task to implement a proof-of-concept desktop GUI using
Guile, and Carol the task to implement a proof-of-concept web GUI using
chicken, while she herself implements the microcontroller using
Gambit/Gerbil.

After implementing the minimal UI prototypes, Bob and Carol ask Alice:
“Which libraries should we use to implement the networking protocol?”

- How does Alice find the answer?
- How did Alice decide which libraries to use herself? Did she have to
restrict herself to the subset of libraries supported by all three
Schemes?


Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
signature.asc

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 4:09:47 AMMar 9
to scheme-re...@googlegroups.com
Am Mi., 9. März 2022 um 08:47 Uhr schrieb Lassi Kortela <la...@lassi.io>:
>
> > Accordingly, if R7RS-Medium is something that is actually going to
> > happen, I would like to see the following.
>
> Agreed on all.
>
> Simple proposal:
>
> - R7RS shall be only R7RS-small.
>
> - The new "medium" language shall be called R8RS, and shall contain
> everything in R6RS and R7RS as optional modules. Otherwise, ask
> implementers what they're willing to put up with.

I'm not quite sure what you mean by "everything as optional modules".
Do you mean that even fundamental things like first-class
continuations, multiple values, procedural macros, or records are
optional?

> - The new "large" language shall be R8RS + the large libraries on top.

If the medium language we are currently discussing as a basis for the
large language has to introduce some significant changes to R7RS-small
and is, at the same time, broad enough so that R6RS can be absorbed
into it as well, then, yes, a name like R8RS would be better. For the
large language, it doesn't matter much whether it is called R7RS-large
or R8RS-large as long as the Medium project helps push the development
of the large language.

The quickest way (but currently seemingly forbidden by the WG 2
charter for reasons I cannot understand) would actually be to base the
medium language on R6RS and, subsequently, the large language as well.
The medium language would have to add enough so that there's also
R7RS-small compatibility. The point is that we have to add everything
that was removed from R6RS to R7RS-small to the language anyway.

> You'd still be hitting the following problems:
>
> - Libraries are by their nature loosely coupled to the core language.
>
> - The library effort intrinsically moves at a different pace than the
> core effort.
>
> - The library effort easily slows down the core effort if they're coupled.
>
> All three have a common cause: There's little reason to tie the
> libraries to any given edition of the core language.

> Currently it seems that for libs the only core language question is
> whether keyword arguments are available or not.

I think there's a lot more like the condition system, available
syntactic facilities, concurrency, etc. that have to be fixed somewhat
by the core.

Lassi Kortela

unread,
Mar 9, 2022, 4:14:39 AMMar 9
to scheme-re...@googlegroups.com, Daphne Preston-Kendal
> I join your concern about cooperation between Medium and Large.

Proponents of Large, please enumerate the Medium features which would
affect what kind of API is exported by Large libraries. You'll find that
there aren't many.

> (define (eligible-for-medium? feature)
> (not (or (r7rs-small-portable? feature)
> (r7rs-small+ffi-implementable? feature))))

Seems reasonable.

Another proposal:

(define (eligible-for-medium? feature)
(< (count (cannot-stand? feature) scheme-implementers)
threshold))

Alex Shinn

unread,
Mar 9, 2022, 4:21:19 AMMar 9
to scheme-re...@googlegroups.com
On Wed, Mar 9, 2022 at 8:52 AM Vincent Manis <vman...@gmail.com> wrote:
>
> Now “Scheme” is not a trademark, and any person or persons can create
> any Scheme standard they like [...]

Which would not be accepted unless chartered by the Steering Committee
and ratified by the broader Scheme community.

--
Alex

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 4:27:22 AMMar 9
to scheme-re...@googlegroups.com
And even that is not a guarantee for success.

Lassi Kortela

unread,
Mar 9, 2022, 4:32:35 AMMar 9
to Dr. Arne Babenhauserheide, scheme-re...@googlegroups.com
> Why "everything … optional"?
>
> If I understand this correctly, it would make programs written for R8RS
> much harder to re-use in another R8RS Scheme.
>
> It would neither be a superset, nor a subset, but more like a sponge.

> With many optional modules, this would make compatibility of the
> libraries with a given Scheme that has a random set of optional modules
> pretty hard.
>
> Either you could not use any core feature from the core language, or
> you’d have to check for each library individually whether you can use
> it.

Correct.

We want the same outcome (i.e. it should be easy to find a variety of
Scheme implementations that all support a useful set of common language
features).

But I anticipate that instead of RnRS prescribing feature sets, it's
better to let the user community empirically find and name good sets.

Most of Scheme's features are easily factored into libraries, and both
R6RS and R7RS have implicitly followed this pricinple. For example,
dropping the (scheme complex) library in R7RS can yield an
implementation without complex number support.

I envision future RnRS as essentially a buffer of libraries that add
features near the core of the language.

If so, a full implementation of R8RS (aka Medium) would run all
practical R6RS code, as well as all practical R7RS-small code, as-is.

But Scheme has a lot of implementers; as a group they are hard to
please. From what I gather, some implementers (and users) really can't
stand R6RS. If we want them aboard an R8RS, we have little choice but to
make the features that came from R6RS optional. Once you follow that
principle (as well as the precendent of R6 and R7) the most natural
design approach starts to look like factoring the whole language into libs.

> As a use-case:
>
> - How does Alice find the answer?
> - How did Alice decide which libraries to use herself? Did she have to
> restrict herself to the subset of libraries supported by all three
> Schemes?

Via a user-friendly implementation browser that we should add to
Scheme.org. I suggest that Scheme's user community should give names to
good subsets of R8RS once we have gained some experience using it in the
field.

Of course, the largest implemntations can always opt to go R8RS Full
from the start. But it'd be nice to get ones like Chibi-Scheme on board
R8RS, and Full seems like a non-starter there.

Daphne Preston-Kendal

unread,
Mar 9, 2022, 4:45:28 AMMar 9
to Lassi Kortela, scheme-re...@googlegroups.com
On 9 Mar 2022, at 10:14, Lassi Kortela <la...@lassi.io> wrote:

>> I join your concern about cooperation between Medium and Large.
>
> Proponents of Large, please enumerate the Medium features which would affect what kind of API is exported by Large libraries. You'll find that there aren't many.

My concern — and I think Vincent’s — is about procedural issues of cooperation, rather than technical issues of interoperation.


Daphne


Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 4:45:32 AMMar 9
to scheme-re...@googlegroups.com, Dr. Arne Babenhauserheide
Am Mi., 9. März 2022 um 10:32 Uhr schrieb Lassi Kortela <la...@lassi.io>:
>
> > Why "everything … optional"?
> >
> > If I understand this correctly, it would make programs written for R8RS
> > much harder to re-use in another R8RS Scheme.
> >
> > It would neither be a superset, nor a subset, but more like a sponge.
>
> > With many optional modules, this would make compatibility of the
> > libraries with a given Scheme that has a random set of optional modules
> > pretty hard.
> >
> > Either you could not use any core feature from the core language, or
> > you’d have to check for each library individually whether you can use
> > it.
>
> Correct.
>
> We want the same outcome (i.e. it should be easy to find a variety of
> Scheme implementations that all support a useful set of common language
> features).
>
> But I anticipate that instead of RnRS prescribing feature sets, it's
> better to let the user community empirically find and name good sets.
>
> Most of Scheme's features are easily factored into libraries, and both
> R6RS and R7RS have implicitly followed this pricinple. For example,
> dropping the (scheme complex) library in R7RS can yield an
> implementation without complex number support.

The problem here is the non-monotonicity of features, I think.

Say, I am writing a library (frob) that exports the frobnicate
procedure that frobnicates every Scheme value. If I want this library
to be fully portable and complete, it has to be able to frobnicate
also complex values. Thus, it either has to important (scheme complex)
unconditionally or it imports (scheme complex) conditionally and
offers effectively two versions of frobnicate, one with and one
without complex number support and exporting the one that would be
supported by the implementation.

In the former case, the library (frob) would not work on Scheme
systems that do not implement complex numbers although frobnicating
their limited set of values should work in principle. In the latter
case, writing the library becomes quite a hassle, especially when it
not only depends on complex number support but also on other optional
parts, probably leading to some combinatorial explosion.

Lassi Kortela

unread,
Mar 9, 2022, 4:55:06 AMMar 9
to scheme-re...@googlegroups.com
> I'm not quite sure what you mean by "everything as optional modules".
> Do you mean that even fundamental things like first-class
> continuations, multiple values, procedural macros, or records are
> optional?

I would be in favor of that(*). I know it sounds radical, but it matches
what Scheme implementations already do in practice.

Modularity would let even the smallest implementations conform to the
latest RnRS, and I don't see the large implementations losing anything;
they can add all of the available libraries, as they have done so far.

What should be required of all implementations? IMHO an R6+R7 compatible
library expander, as well as R6+R7 compatible lexical syntax.

(*) (Not 100% sure about multiple values, but it seems doable.)

> If the medium language we are currently discussing as a basis for the
> large language has to introduce some significant changes to R7RS-small
> and is, at the same time, broad enough so that R6RS can be absorbed
> into it as well, then, yes, a name like R8RS would be better. For the
> large language, it doesn't matter much whether it is called R7RS-large
> or R8RS-large as long as the Medium project helps push the development
> of the large language.

Indeed, it increasingly seems that tying the large language to a
specific RnRS number may not make sense to begin with. A lot of pressure
would let up if it could plot its own course.

> The quickest way (but currently seemingly forbidden by the WG 2
> charter for reasons I cannot understand) would actually be to base the
> medium language on R6RS and, subsequently, the large language as well.
> The medium language would have to add enough so that there's also
> R7RS-small compatibility. The point is that we have to add everything
> that was removed from R6RS to R7RS-small to the language anyway.

100% agreed.

>> Currently it seems that for libs the only core language question is
>> whether keyword arguments are available or not.

> I think there's a lot more like the condition system, available
> syntactic facilities, concurrency, etc. that have to be fixed somewhat
> by the core.

Good point. It would indeed be nice if the Large libraries raise
conditions that are in harmony with the Medium/R8RS language.

Macro systems mainly affect implementation; is there any place where the
API exported by Large libraries is constrained by choice of macro
systems? In a pinch, Schemes that are not big enough to have syntax-case
can use `define-macro` for procedural macros.

Concurrency and continuations raise issues with all Scheme APIs, but do
they affect procedure call syntax? Probably not.

Lassi Kortela

unread,
Mar 9, 2022, 5:46:16 AMMar 9
to scheme-re...@googlegroups.com, Marc Nieper-Wißkirchen, Dr. Arne Babenhauserheide
> Say, I am writing a library (frob) that exports the frobnicate
> procedure that frobnicates every Scheme value. If I want this library
> to be fully portable and complete, it has to be able to frobnicate
> also complex values. Thus, it either has to important (scheme complex)
> unconditionally or it imports (scheme complex) conditionally and
> offers effectively two versions of frobnicate, one with and one
> without complex number support and exporting the one that would be
> supported by the implementation.
>
> In the former case, the library (frob) would not work on Scheme
> systems that do not implement complex numbers although frobnicating
> their limited set of values should work in principle. In the latter
> case, writing the library becomes quite a hassle, especially when it
> not only depends on complex number support but also on other optional
> parts, probably leading to some combinatorial explosion.

Something like the code below?

In general, writing things that work on all types of values is tricky.
No practical Scheme system is likely to have _only_ the data types
defined by RnRS. At the same time, subsets without all those types are
useful.

A generic functions facility would be a tried and true way to write
things that work on an open set of data types. GFs feature prominently
in Common Lisp. I think we should add them to Scheme as well (though not
to RnRS - at least not to the next version - and not as a required part).

(define-library (frob)
(export frobnicate)
(import (scheme base))
(cond-expand
((library (scheme complex))
(import (scheme complex))))
(cond-expand
((library (scheme complex))
(begin
(define (frobnicate-complex x)
(and (complex? x)
(do-something-with (real-part x) (imag-part x))))))
(else
(begin
(define (frobnicate-complex x)
#f))))
(begin

(define (frobnicate-symbol x)
(and (symbol? x)
...))

(define (frobnicate-string x)
(and (string? x)
...))

(define (frobnicate x)
(or (frobnicate-symbol x)
(frobnicate-string x)
...
(frobnicate-complex x)))))

Dr. Arne Babenhauserheide

unread,
Mar 9, 2022, 6:07:15 AMMar 9
to Marc Nieper-Wißkirchen, scheme-re...@googlegroups.com
That’s the point I’m trying to make, but you used the proper wording.


(In the following I use strong expressions — not in the sense of insult,
but in the sense of describing dire, far-reaching implications. This is
not meant as insult, but as clear warning. It is also not targeted at
any person, only at the concept. I’m using this strong wording, because
I had two Kassandra-moments in the past year where I did not word
warnings strongly enough, and I want to avoid that here)


Combinatorial explosion is what kills the idea of lots of independently
optional parts. And I’m serious about the "kills". The amount of
portability problems this causes rises super-exponentially with the
size of the program you’re writing.

That would cause the worst possible programming experience, because
problems would show up as late as possible in any project. You add that
one required library for a specific feature-request, and when gathering
the requirements for that feature, you realize that you would completely
tie off a part of your target platforms, so you won’t ever be able to
provide that feature on budget.

If we did that, using multiple scheme implementations in related
projects would not be a programming environment I could sincerely
recommend to anyone.


So it would increase the tribalism we already see („stick to your
scheme“, „choose your tribe“, …), which is a problem that a common
standard should reduce, not strengthen.
And this would kill a strength of Scheme: That you can have the same
language on any level of abstraction and distance to hardware — from
microcontrollers to browser-based web-applications.
signature.asc

Lassi Kortela

unread,
Mar 9, 2022, 6:25:13 AMMar 9
to scheme-re...@googlegroups.com, Dr. Arne Babenhauserheide, Marc Nieper-Wißkirchen
> (In the following I use strong expressions — not in the sense of insult,
> but in the sense of describing dire, far-reaching implications. This is
> not meant as insult, but as clear warning. It is also not targeted at
> any person, only at the concept. I’m using this strong wording, because
> I had two Kassandra-moments in the past year where I did not word
> warnings strongly enough, and I want to avoid that here)

This is probably cultural, but I didn't notice any strong words.

> Combinatorial explosion is what kills the idea of lots of independently
> optional parts. And I’m serious about the "kills". The amount of
> portability problems this causes rises super-exponentially with the
> size of the program you’re writing.
>
> That would cause the worst possible programming experience, because
> problems would show up as late as possible in any project. You add that
> one required library for a specific feature-request, and when gathering
> the requirements for that feature, you realize that you would completely
> tie off a part of your target platforms, so you won’t ever be able to
> provide that feature on budget.
>
> If we did that, using multiple scheme implementations in related
> projects would not be a programming environment I could sincerely
> recommend to anyone.
>
> So it would increase the tribalism we already see („stick to your
> scheme“, „choose your tribe“, …), which is a problem that a common
> standard should reduce, not strengthen.
> And this would kill a strength of Scheme: That you can have the same
> language on any level of abstraction and distance to hardware — from
> microcontrollers to browser-based web-applications.

The wide range of implementations is enabled by dropping a lot of the
more involved stuff. The microcontroller Schemes have very few features
(even the string library may be superfluous there). The simplest
embedded Schemes (for dropping easily into a C program) cannot be relied
on to have something like syntax-case or complex numbers - those
features are not useful when a C programmer just wants to write part of
a simple program in Scheme.

A complex implementation like Chez, Gambit, Gauche, or Guile can be
embedded in C, but it's overkill except for a relatively big
application. The proponents of those implementations tend to say it's
easy, but it's not. The wide range of Scheme implementation lets you
start with something trivial like TinyScheme, and work your way up as
the C program grows.

The upshot is that people will keep making interpreters like TinyScheme
anyway. The big-implementations-only camp will say that those are not
really Scheme. But what else should one call a language that looks and
works exactly like Scheme; has the essential character of Scheme but is
just missing some non-core features?

It's unlikely that we could force a substantial part of the existing
Scheme implementations to add a wide range of data types and libraries
dissimilar to what they already have.

At the same time, I agree that programmers wishing to figure out what
language features to use for their project should find it easy to choose
a widely supported subset of Scheme. I expect (but don't know) that if
the user community pick memorable names for useful subsets (similar to
the R7RS-large Red, Orange, etc. but more differentiated) those subsets
will become recognizable brands in their own right.

We could give the popular subsets official designations after the fact,
so that people can (import (scheme red)) and things like that.

(Once again, we arrive at a prestige system for what to add to the
"scheme" namespace, this time by a different route.)

Dr. Arne Babenhauserheide

unread,
Mar 9, 2022, 7:38:31 AMMar 9
to Lassi Kortela, scheme-re...@googlegroups.com, Marc Nieper-Wißkirchen

Lassi Kortela <la...@lassi.io> writes:

>> (In the following I use strong expressions — not in the sense of insult,
>> but in the sense of describing dire, far-reaching implications. This is
>> not meant as insult, but as clear warning. It is also not targeted at
>> any person, only at the concept. I’m using this strong wording, because
>> I had two Kassandra-moments in the past year where I did not word
>> warnings strongly enough, and I want to avoid that here)
>
> This is probably cultural, but I didn't notice any strong words.

I wrote „kills the idea“, won’t ever be able, could not sincerely
recommend, …

That’s wording which people could easily see as insulting, that’s why I
wrote the info up front that this is about the idea, not any person.

>> And this would kill a strength of Scheme: That you can have the same
>> language on any level of abstraction and distance to hardware — from
>> microcontrollers to browser-based web-applications.
>
> The wide range of implementations is enabled by dropping a lot of the
> more involved stuff. The microcontroller Schemes have very few
> features (even the string library may be superfluous there). The
> simplest embedded Schemes (for dropping easily into a C program)
> cannot be relied on to have something like syntax-case or complex
> numbers - those features are not useful when a C programmer just wants
> to write part of a simple program in Scheme.

That’s why I like the idea of R7RS-small and R7RS-large so much: To
build something that works across Schemes, I can restrict myself to
R7RS-small.

Alice can build the microcontroller in R7RS-small and be sure that all
the features she uses will also be available to Bob and Carol in Guile
and Chicken (if/when those report R7RS-large support).

She can tell them to ensure that everything that’s needed for
communicating with the microcontroller must be available for R7RS-small.
That’s an easy to give and easy to check requirement.

If you have 5 or 6 different categories, this becomes hard. If you have
20 or 30, it is no longer viable.

> The upshot is that people will keep making interpreters like
> TinyScheme anyway. The big-implementations-only camp

I do not see such a camp here. Am I missing something?

> that if the user community pick memorable names for useful subsets
> (similar to the R7RS-large Red, Orange, etc. but more differentiated)
> those subsets will become recognizable brands in their own right.

I think that creating these subsets is what we’re doing right now. We
*are* the user community that cares about finding subsets.

One of those is R7RS-small. That’s already finished. One is what
R7RS-large can become. R7RS-medium is something on the way there: A
differentiator between small systems and large systems.

We could provide that as useful requirements-info in libraries: Does
this work on R7RS-small or does it require R7RS-medium?

> We could give the popular subsets official designations after the
> fact, so that people can (import (scheme red)) and things like that.
>
> (Once again, we arrive at a prestige system for what to add to the
> "scheme" namespace, this time by a different route.)

I still do not see this as prestige. It is a service to other users to
identify and provide the common tools that should be available.

It is what I as a user need.
signature.asc

Lassi Kortela

unread,
Mar 9, 2022, 8:50:46 AMMar 9
to scheme-re...@googlegroups.com
> That’s why I like the idea of R7RS-small and R7RS-large so much: To
> build something that works across Schemes, I can restrict myself to
> R7RS-small.
>
> Alice can build the microcontroller in R7RS-small and be sure that all
> the features she uses will also be available to Bob and Carol in Guile
> and Chicken (if/when those report R7RS-large support).
>
> She can tell them to ensure that everything that’s needed for
> communicating with the microcontroller must be available for R7RS-small.

The extant microcontroller Schemes that I know of are:

Bit
https://www.iro.umontreal.ca/~feeley/papers/DubeFeeleyHOSC05.pdf

Picbit
https://www.iro.umontreal.ca/~feeley/papers/sw03.pdf
http://lambda-the-ultimate.org/node/3694

Picobit (with an "o")
https://www.ccs.neu.edu/home/stamourv/papers/picobit.pdf
https://github.com/stamourv/picobit

Armpit
http://armpit.sourceforge.net/
https://github.com/RaD/ArmpitScheme

Microscheme
https://github.com/ryansuchocki/microscheme

None of these conform to R7RS-small, and probably never will.

If you intend to make the point that we should have a tower of
increasingly bigger standard module sets, such that every set is a
subset of all the bigger sets, that I agree is a good idea. In everyday
language, anyone using Medium Scheme would be guaranteed access to all
libraries in Small Scheme. Anyone using Large Scheme would be guaranteed
to have all the libraries in Medium Scheme.

> That’s an easy to give and easy to check requirement.
>
> If you have 5 or 6 different categories, this becomes hard. If you have
> 20 or 30, it is no longer viable.

I agree. 5 it about the maximum, less than 5 is ideal. Maybe 3 or 4?

>> The big-implementations-only camp

> I do not see such a camp here. Am I missing something?

Not sure whether there are people with that opinion in this discussion,
but I've met at least one or two on Scheme lists. Can't remember who.

They do have a point in that small implementations inevitably dilute the
name of "Scheme" as a featureful language, at least a little bit.
Similarly, some people argue that calling Scheme a Lisp dilutes the name
of "Lisp" since Scheme is not compatible.

But people who call Scheme a Lisp, and who call TinyScheme a Scheme, do
have a point as well.

>> that if the user community pick memorable names for useful subsets
>> (similar to the R7RS-large Red, Orange, etc. but more differentiated)
>> those subsets will become recognizable brands in their own right.

> I think that creating these subsets is what we’re doing right now. We
> *are* the user community that cares about finding subsets.

Sure. It's just a question of who should decide the subsets: the authors
of RnRS at publication time, or its users after the fact.

We can avoid publishing separate Small and Medium standards for R8RS.
They can be the same document. This is a huge win IMHO - it's easiest to
understand and verify the correctness of the standard if it's one document.

If there are more than two standard module sets, this further supports
the opinion that there should be only one document that specifies the
full set.

> One of those is R7RS-small. That’s already finished. One is what
> R7RS-large can become. R7RS-medium is something on the way there: A
> differentiator between small systems and large systems.
>
> We could provide that as useful requirements-info in libraries: Does
> this work on R7RS-small or does it require R7RS-medium?

I agree that this is ideal, we should definitely come up with simple
names like that one way or another.

> I still do not see this as prestige. It is a service to other users to
> identify and provide the common tools that should be available.
>
> It is what I as a user need.

Prestige is universal - it's the basic currency of the economics of
social status which underlies most human behavior. "Scheme" is more
prestigious than "Froz" because people trust Scheme whereas nobody knows
what Froz is.

Martin Rodgers

unread,
Mar 9, 2022, 9:29:33 AMMar 9
to scheme-re...@googlegroups.com
On 09/03/2022, Lassi Kortela <la...@lassi.io> wrote:

> We can avoid publishing separate Small and Medium standards for R8RS.
> They can be the same document. This is a huge win IMHO - it's easiest to
> understand and verify the correctness of the standard if it's one document.

I think it's premature to use the name R8RS. Everything you want can
be done with R7RS Small. I mean *everything*.

Why not simply define R7RS Small plus subsets of the SRFI set? Why
make any of this more complicated? Such sets can be defined
independantly of WG2. In fact, that's what I've been doing since R7RS
Small appeared in 2013. How is this any different from R5RS + a SRFI
subset, as defined by the various R5RS implementations? Likewise R6RS.

So what's new now? What changed? Has WG2 decided to mandate the entire
R7RS Large set? Did I miss that? The only Large mandate I recall is
that everything in Small is required. Can someone please clarify this?
What is the current policy?

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 9:40:51 AMMar 9
to scheme-re...@googlegroups.com
Am Mi., 9. März 2022 um 15:29 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:
>
> On 09/03/2022, Lassi Kortela <la...@lassi.io> wrote:
>
> > We can avoid publishing separate Small and Medium standards for R8RS.
> > They can be the same document. This is a huge win IMHO - it's easiest to
> > understand and verify the correctness of the standard if it's one document.
>
> I think it's premature to use the name R8RS. Everything you want can
> be done with R7RS Small. I mean *everything*.
>
> Why not simply define R7RS Small plus subsets of the SRFI set? Why
> make any of this more complicated? Such sets can be defined
> independantly of WG2. In fact, that's what I've been doing since R7RS
> Small appeared in 2013. How is this any different from R5RS + a SRFI
> subset, as defined by the various R5RS implementations? Likewise R6RS.

I think the main reason that speaks against this otherwise obviously
sounding idea is that the whole is more than the sum of its parts. The
addition of each SRFI modifies the base language, say R5RS, in some
way (for an explicit example the spec of SRFI 9, which states how R5RS
is to be amended). Amending a document is, however, not a commutative
operation in general. It's not even an operation in the mathematical
sense. By that, I mean that even when it is clear what it means to add
either SRFI X or SRFI Y to the base language, it is not necessarily
clear what it means to add both SRFI X and Y in a compatible way.

For many SRFIs, this is nevertheless possible and such SRFIs are good
candidates for inclusion in the large language. More fundamental
modifications of the base language have eventually to be done
monolithically. (A good example is the addition of multiple values
from R4RS to R5RS. There could have been, of course, a SRFI for
multiple values instead but that wouldn't have made all other SRFIs
multiple-value aware.)

Marc

Lassi Kortela

unread,
Mar 9, 2022, 9:52:43 AMMar 9
to scheme-re...@googlegroups.com
> Why not simply define R7RS Small plus subsets of the SRFI set?

RnRS defines the lexical syntax and the library definition metalanguage.
The R6RS and R7RS-small versions of these things are incompatible. IMHO,
these incompatibilities make portable coding a complete mess. Once you
have these you can use cond-expand to deal with the remaining problems.

Of course we doule define lexical syntax and the library language in
SRFIs. But then, all of R5RS could be defined in SRFIs. Do you think the
RnRS series should even exist to begin with?

Apart from the above, RnRS gives the opportunity to put every aspect of
the core language in one document that is high-quality, internally
consistent, and comes with a formal proof of the semantics. The
precision of SRFIs varies widely; almost none of them are up to the
standard of R6RS in this respect.

> Has WG2 decided to mandate the entire R7RS Large set?

AFAIK there are no plans for any such mandate.

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 10:03:43 AMMar 9
to scheme-re...@googlegroups.com
Am Mi., 9. März 2022 um 15:52 Uhr schrieb Lassi Kortela <la...@lassi.io>:
>
> > Why not simply define R7RS Small plus subsets of the SRFI set?
>
> RnRS defines the lexical syntax and the library definition metalanguage.
> The R6RS and R7RS-small versions of these things are incompatible. IMHO,
> these incompatibilities make portable coding a complete mess. Once you
> have these you can use cond-expand to deal with the remaining problems.

With all due respect, "complete mess" is an exaggeration as the
library definition language really sits at the border between the
proper Scheme system and the host environment. And the differences in
lexical syntax seem minor, or am I missing something here?

[...]

Arthur A. Gleckler

unread,
Mar 9, 2022, 10:31:05 AMMar 9
to scheme-re...@googlegroups.com
On Tue, Mar 8, 2022 at 11:39 PM Daphne Preston-Kendal <d...@nonceword.org> wrote:
 
I join your concern about cooperation between Medium and Large. It depends how those who have less interest in the Medium effort want to proceed. One way would be to delay further ballots on Large until Medium is done: this would not preclude further Large work, but keep it within the SRFI process until Medium is done....

 Please do not delay Large any further.  Even if the Steering Committee approves of the idea of Medium, delaying Large further is the last thing we need.

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 10:40:19 AMMar 9
to scheme-re...@googlegroups.com
Am Mi., 9. März 2022 um 16:31 Uhr schrieb Arthur A. Gleckler
<a...@speechcode.com>:
>
> On Tue, Mar 8, 2022 at 11:39 PM Daphne Preston-Kendal <d...@nonceword.org> wrote:
>
>>
>> I join your concern about cooperation between Medium and Large. It depends how those who have less interest in the Medium effort want to proceed. One way would be to delay further ballots on Large until Medium is done: this would not preclude further Large work, but keep it within the SRFI process until Medium is done....
>
>
> Please do not delay Large any further. Even if the Steering Committee approves of the idea of Medium, delaying Large further is the last thing we need.

Delaying ballots as Daphne suggests as one possibility does not
necessarily mean that the delivery of the final product of the Large
process is delayed, I think.

Personally, I'd like to see that work on both standards happens
somewhat in parallel. I have the feeling that a lot of the issues that
recently came up have their root cause in the fact the R7RS-small and
R7RS-large eventually weren't developed in parallel. I guess, back
then, there were good reasons for completing the small language before
work on the large one was effectively started but I don't want to
repeat that necessarily.

Martin Rodgers

unread,
Mar 9, 2022, 11:02:23 AMMar 9
to scheme-re...@googlegroups.com
On 09/03/2022, Lassi Kortela <la...@lassi.io> wrote:
>> Why not simply define R7RS Small plus subsets of the SRFI set?
>
> RnRS defines the lexical syntax and the library definition metalanguage.
> The R6RS and R7RS-small versions of these things are incompatible. IMHO,
> these incompatibilities make portable coding a complete mess. Once you
> have these you can use cond-expand to deal with the remaining problems.

I said earlier that I "committed to R7RS", but I now think the word
"invested" would be more appropriate. I have 22+K lines of R7RS code.
I've not written code in R6RS since 2009, when work on R7RS was
announced. Other Scheme programmers continued to use R6RS and write,
and share new libraries for R6RS. Some of them will likely have far
more than 22+Kloc of R6RS as their investments.

I accept that you have investments in R6RS. Nobody is forcing you to
stop using it or abandone your code. I understand why anyone invested
in a report would like to continue and extend that investment.

You're free to do so, but the correct time to object to R7RS and point
out what you describe as "incompatibilities" was before the vote on
R7RS in 2013. It was clear to everyone what WG1's purpose was long
before 2013.

We all know the result. It's why WG2 exists.

So I refute the use of the phrase "complete mess" in this context.
Please don't use it as a straw man. I'll simply point out the straw
man nature of your argument and dismiss it, as I'm doing now.

> AFAIK there are no plans for any such mandate.

No such mandate, no "complete mess." I refer you to my above points
and to points in my earlier posts on this subject. I don't wish to go
on about this at tedious length when there's an archive available for
everyone to read.

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 11:18:41 AMMar 9
to scheme-re...@googlegroups.com
Am Mi., 9. März 2022 um 17:02 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:

> You're free to do so, but the correct time to object to R7RS and point
> out what you describe as "incompatibilities" was before the vote on
> R7RS in 2013. It was clear to everyone what WG1's purpose was long
> before 2013.

While Lassi wasn't around at that time, it should be noted that there
were tickets criticizing these points, e.g.:

https://small.r7rs.org/ticket/481/

The following ticket is also related:

https://small.r7rs.org/ticket/486/

If these tickets had been resolved differently, we wouldn't probably
have the current discussion.

Marc

Lassi Kortela

unread,
Mar 9, 2022, 11:36:32 AMMar 9
to scheme-re...@googlegroups.com, Martin Rodgers
> You're free to do so, but the correct time to object to R7RS and point
> out what you describe as "incompatibilities" was before the vote on
> R7RS in 2013. It was clear to everyone what WG1's purpose was long
> before 2013.
>
> We all know the result. It's why WG2 exists.
>
> So I refute the use of the phrase "complete mess" in this context.

RnRS is just a document. It should enable people to do useful things
with Scheme. Currently it's blocking people from doing useful things.

We should have one Scheme with, at a minimum:

- compatible lexical syntax

- compatible library definition syntax

- compatible filename patterns

Anything that achieves that is good.

Anything document or process worship which detracts from that is bad.

If R8RS, R7RS-medium, or R7RS-large are bad ways to accomplish the
above, we're open to other suggestions. Relying on Scheme implementers
to support both R6RS and R7RS (as they are) isn't working out - we've
had years to work it out.

Martin Rodgers

unread,
Mar 9, 2022, 11:48:01 AMMar 9
to scheme-re...@googlegroups.com
However, that's my point. There was a vote and that faction lost. It
may seem unfair to deny latecomers any voice in that debate, but
revising the work of WG1 now can only undermine their work. See my
points on this below, at the end of this post.

I agree with Arthur's recent post. This thread has the potential to
delay Large. Perhaps it is *already* doing so.

No argument here is convincing me that there's a need to discuss
Medium or R8RS before Large is completed. (See my final point, below.)

All the talk about R6RS reminds me of arguments I've seen elsewhere,
which have the potential to derail the entire project. I've even seen
one participate (in a legislative context) describe a proposed
amendment, at a very late state in the process, as a "wrecking
amendment", and then give a short lecture on correct procedure. While
I don't consider anything in this discussion that destructive, there's
an argument that it is delaying work on R7RS Large.

Meanwhile, the "no mandate" point is where we can all agree - and that
means this discussion can be postponed until Large is completed. It
will still be possible to talk about Medium.

However, any talk of R8RS at this point is looks like a wrecking move
to me. Please wait until Large and Medium are completed before
starting *that*.

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 11:59:45 AMMar 9
to scheme-re...@googlegroups.com
Am Mi., 9. März 2022 um 17:48 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:
>
> On 09/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
> > Am Mi., 9. März 2022 um 17:02 Uhr schrieb Martin Rodgers
> > <mcro...@gmail.com>:
> >
> >> You're free to do so, but the correct time to object to R7RS and point
> >> out what you describe as "incompatibilities" was before the vote on
> >> R7RS in 2013. It was clear to everyone what WG1's purpose was long
> >> before 2013.
> >
> > While Lassi wasn't around at that time, it should be noted that there
> > were tickets criticizing these points, e.g.:
> >
> > https://small.r7rs.org/ticket/481/
> >
> > The following ticket is also related:
> >
> > https://small.r7rs.org/ticket/486/
> >
> > If these tickets had been resolved differently, we wouldn't probably
> > have the current discussion.
>
> However, that's my point. There was a vote and that faction lost. It
> may seem unfair to deny latecomers any voice in that debate, but
> revising the work of WG1 now can only undermine their work. See my
> points on this below, at the end of this post.

It should be noted that the "other faction" seemingly mostly abstained
from voting when I look at the list of people taking part in the vote
on R7RS-small. Thus, the R7RS situation is not that different from the
R6RS situation. Or, in other words, by the same arguments, R7RS
shouldn't have been started because it could only undermine the work
of the R6RS editors.

Anyway, I am a mathematician and not a lawyer. It's not the process,
it is the result that's important to me.

> I agree with Arthur's recent post. This thread has the potential to
> delay Large. Perhaps it is *already* doing so.

I agree that such a danger exists and that we have to be aware of it.

> No argument here is convincing me that there's a need to discuss
> Medium or R8RS before Large is completed. (See my final point, below.)
>
> All the talk about R6RS reminds me of arguments I've seen elsewhere,
> which have the potential to derail the entire project. I've even seen
> one participate (in a legislative context) describe a proposed
> amendment, at a very late state in the process, as a "wrecking
> amendment", and then give a short lecture on correct procedure. While
> I don't consider anything in this discussion that destructive, there's
> an argument that it is delaying work on R7RS Large.
>
> Meanwhile, the "no mandate" point is where we can all agree - and that
> means this discussion can be postponed until Large is completed. It
> will still be possible to talk about Medium.
>
> However, any talk of R8RS at this point is looks like a wrecking move
> to me. Please wait until Large and Medium are completed before
> starting *that*.

R8RS is just a name. Work on Large or Medium should not be affected
whether the end result will be called R8RS or R7RS. It may have a
political impact, though. But maybe I misunderstood you.

Lassi Kortela

unread,
Mar 9, 2022, 12:27:24 PMMar 9
to scheme-re...@googlegroups.com, Marc Nieper-Wißkirchen
I agree with all of Marc's comments in the last mail.

R7RS-large is estimated to take several more years. It takes time due to
its scope, and because there has been persistent disagreement with its
goals and process which taxes morale.

If something like R7RS-medium (or R8RS - the name is not a deal breaker)
isn't done, I will start a fork so we can ship an R6RS + R7RS-small
compatibility standard in a timely manner.

However, I greatly respect John's proclivity to work out a deal with
people who persistently disagree with him. I'm sure we can either start
an official Medium project, or if we start an unofficial fork, that we
can synchronize the fork with the corresponding parts of R7RS-large so
both are compatible. None of us want incompatibility.

As an aside, the pacing at https://registry.scheme.org/#scheme-standard
indicates it would be a good time to ship the next RnRS soon.

Martin Rodgers

unread,
Mar 9, 2022, 12:42:55 PMMar 9
to scheme-re...@googlegroups.com
On 09/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

>> However, that's my point. There was a vote and that faction lost. It
>> may seem unfair to deny latecomers any voice in that debate, but
>> revising the work of WG1 now can only undermine their work. See my
>> points on this below, at the end of this post.
>
> It should be noted that the "other faction" seemingly mostly abstained
> from voting when I look at the list of people taking part in the vote
> on R7RS-small. Thus, the R7RS situation is not that different from the
> R6RS situation. Or, in other words, by the same arguments, R7RS
> shouldn't have been started because it could only undermine the work
> of the R6RS editors.

I think we are in agreement on this. My position is simple. This is
not a zero-sum game.

> Anyway, I am a mathematician and not a lawyer. It's not the process,
> it is the result that's important to me.

I'm merely a programmer.

>> However, any talk of R8RS at this point is looks like a wrecking move
>> to me. Please wait until Large and Medium are completed before
>> starting *that*.
>
> R8RS is just a name. Work on Large or Medium should not be affected
> whether the end result will be called R8RS or R7RS. It may have a
> political impact, though. But maybe I misunderstood you.

Using the R8RS now in WG2 is surely premature. It may even be out of
place. Was there discussing of R7RS during work on R6RS? Was there
discussion of R6RS during work on R5RS. Was there discussion of R5RS
during the R4RS process?

I don't know, but R4 was published in 1991. R5RS was published in
1997. I recall some criticisms made in comp.lang.scheme, but the
community moved on and accepted the report. Many Scheme systems based
on the report were created, maintained etc, and as we've seen over the
years, it is also being used. I don't doubt it'll continue to be used
for many more years, and thrive.

R6RS was published in 2008 and was met by some with extreme hostility.
There were 4+ Scheme systems based on the report were created,
maintained etc, and as we've seen over the years, it is also being
used. I don't doubt it'll continue to be used for many more years, and
thrive.

Work on R7RS was announced in 2009. I only watched passively during
that debate in comp.lang.scheme. I had no part in discussion of any
report until this year. I don't see how anything WG2 can undermine the
R6RS Scheme systems and the community that use them.

This is not a zero-sum game. No schism is needed.

Martin Rodgers

unread,
Mar 9, 2022, 12:43:36 PMMar 9
to Lassi Kortela, scheme-re...@googlegroups.com
On 09/03/2022, Lassi Kortela <la...@lassi.io> wrote:
>> You're free to do so, but the correct time to object to R7RS and point
>> out what you describe as "incompatibilities" was before the vote on
>> R7RS in 2013. It was clear to everyone what WG1's purpose was long
>> before 2013.
>>
>> We all know the result. It's why WG2 exists.
>>
>> So I refute the use of the phrase "complete mess" in this context.
>
> RnRS is just a document. It should enable people to do useful things
> with Scheme. Currently it's blocking people from doing useful things.

I refute your straw man argument.

This isn't a zero-sum game, as your argument implies. Systems like
Larceny, Guile, Racket etc have existed for years. They all
demonstrate the ease of supporting multiple, divergemt languages
within the same Scheme system. Likewise, systems which support only
one report have also existed for years and continue to be used. I find
it suprising that you ignore this. I'm a little tired of pointing it
out, only for you to ignore it *again*.

> We should have one Scheme with, at a minimum:

Zero-sum thinking. You already have what you want. If you want a
single Scheme, just pick an existing report and use systems that
support it.

This isn't a zero-sum game, as your argument implies. Systems like
Larceny, Guile, Racket etc have existed for years. They all
demonstrate the ease of supporting multiple languages within the same
Scheme system. Likewise, systems which support only one report have
also existed for years and continue to be used. You already *have*
what you want.

This is getting repetitious. Please address my counter-arguments
*without* using straw man arguments. If you can't do that, I see no
point in further debate with you. It wastes time and delays R7RS
Large. Any discussion of R7RS Medium can be done after that.

When all the dust settles on R7RS, then it may be time to consider
talk about R8RS. This may be another reason for me to cease responding
to your straw man arguments. They delay *everything* WG2 is doing.
They may even undermine the work on WG1.

I can see that you're unhappy with that work, but R7RS Small diverged
from R6RS a long time ago. You can read the archives to see that. You
can also see the result, in 2013. However, talking about R8RS here and
now is premature. I don't see how that has any place in WG2. I don't
see how it can do anything but wreck the process.

I'm not suggesting that you are intentially wrecking this process, but
looks like its delaying work on R7RS Large. I've not see any progress
made on that front recently, and I thought that's the stated purpose
of WG2. Regarding the WG2 charter, I see great progress has been made
so far. Many features in R6RS have been considered, voted on, and
approved via a democratic process.

Another objective in the WG2 charter is self-consistancy, in the
"Requirements and Goals" section. I fully support discuss of *that*.
What progress are we making here on that? I don't believe R8RS or
Medium has any relevance to that question. I'm open to pursuasion on
Medium. but R8RS surely has no relevance in WG2.

Instead, I refer you to the "Coordination with Working Group 1"
charter section. Perhaps Medium could help there, but I see nothing
helpful from R8RS in that regard.

Once again, I wish to thank Daphne for starting this thread. Can we
avoid getting side-tracked by straw men and get back to the original
questions?

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 12:56:38 PMMar 9
to scheme-re...@googlegroups.com, Lassi Kortela
Am Mi., 9. März 2022 um 18:43 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:

> This isn't a zero-sum game, as your argument implies. Systems like
> Larceny, Guile, Racket etc have existed for years. They all
> demonstrate the ease of supporting multiple, divergemt languages
> within the same Scheme system. Likewise, systems which support only
> one report have also existed for years and continue to be used. I find
> it suprising that you ignore this. I'm a little tired of pointing it
> out, only for you to ignore it *again*.

It should be noted that neither Larceny nor Guile, nor Racket support
*any* of the Scheme reports in the sense that, say, GCC is aiming at
supporting ISO C fully. The point is that Larceny, Guile, and Racket
all have to make compromises due to the different languages they try
to support at the same time.

The situation is different with systems like Chibi or Chez, which
successfully aim to support one standard fully.

I'm mentioning this because this may underlie Lassi's initial point of
the search for a Scheme standard that attracts more implementations to
support it fully in the GCC sense from my example above.

Lassi Kortela

unread,
Mar 9, 2022, 1:28:52 PMMar 9
to Martin Rodgers, scheme-re...@googlegroups.com
> Systems like
> Larceny, Guile, Racket etc have existed for years. They all
> demonstrate the ease

These implementations make a good effort, but they can't or won't make
it easy enough. AFAICT that's due to the RnRS split.

> of supporting multiple, divergemt languages
> within the same Scheme system.

There should be one language, not multiple divergent languages. The
whole job of RnRS is to solve that problem. If it doesn't solve that
problem, it has failed at its primary mission.

> I'm a little tired of pointing it
> out, only for you to ignore it*again*.

I ignore document worship, process worship, and tradition worship.

Scheme should be easy to use. That's what I care about.

> You already have what you want.

If I already had what I want, I'd notice.

> If you want a
> single Scheme, just pick an existing report and use systems that
> support it.

Programming is a social activity. If I pick one report and my friend
picks another report, making our code interoperate is difficult.

In many or most instances of this problem, there's nothing intrinic
about our code that should make it difficult. It's difficult due to
random accidents of history.

> However, talking about R8RS here and
> now is premature. I don't see how that has any place in WG2. I don't
> see how it can do anything but wreck the process.

It won't wreck the process because John is a sensible guy. He'll make a
deal with people who want a Medium language, like he has done in other
projects previously.

WG2 is free to kick me out at any time. But a language that favors
process sticklers over people who try to solve practical problems is
doomed to obscurity. Productive people like John understand that.

> Another objective in the WG2 charter is self-consistancy, in the
> "Requirements and Goals" section. I fully support discuss of*that*.

I'm skeptical that people can make a self-consistent language the size
of R7RS-large as it is planned, but kudos to those who want to try.

Dr. Arne Babenhauserheide

unread,
Mar 9, 2022, 2:32:12 PMMar 9
to scheme-re...@googlegroups.com, Lassi Kortela

Lassi Kortela <la...@lassi.io> writes:

>> That’s why I like the idea of R7RS-small and R7RS-large so much: To
>> build something that works across Schemes, I can restrict myself to
>> R7RS-small.
>> Alice can build the microcontroller in R7RS-small and be sure that
>> all
>> the features she uses will also be available to Bob and Carol in Guile
>> and Chicken (if/when those report R7RS-large support).
>> She can tell them to ensure that everything that’s needed for
>> communicating with the microcontroller must be available for R7RS-small.
>
> The extant microcontroller Schemes that I know of are:
>
> Bit
> https://www.iro.umontreal.ca/~feeley/papers/DubeFeeleyHOSC05.pdf
>
> Picbit
> https://www.iro.umontreal.ca/~feeley/papers/sw03.pdf
> http://lambda-the-ultimate.org/node/3694
>
> Picobit (with an "o")
> https://www.ccs.neu.edu/home/stamourv/papers/picobit.pdf
> https://github.com/stamourv/picobit
>
> Armpit
> http://armpit.sourceforge.net/
> https://github.com/RaD/ArmpitScheme
>
> Microscheme
> https://github.com/ryansuchocki/microscheme

Thank you for that list! I only knew microscheme.

> None of these conform to R7RS-small, and probably never will.
>
> If you intend to make the point that we should have a tower of
> increasingly bigger standard module sets, such that every set is a
> subset of all the bigger sets, that I agree is a good idea.

That sounds like a good idea. R7RS-tiny?

If something is missing from only one implementation, it might be a good
idea to ask its implementer(-s), whether they would add that before
excluding it from the standard.

> In
> everyday language, anyone using Medium Scheme would be guaranteed
> access to all libraries in Small Scheme. Anyone using Large Scheme
> would be guaranteed to have all the libraries in Medium Scheme.
>
>> That’s an easy to give and easy to check requirement.
>> If you have 5 or 6 different categories, this becomes hard. If you
>> have
>> 20 or 30, it is no longer viable.
>
> I agree. 5 it about the maximum, less than 5 is ideal. Maybe 3 or 4?

That sounds good. And I think we’re already getting there if we want a
Scheme for microcontrollers, a small Scheme, a medium Scheme and a large
Scheme.

That’s already 4 categories, so there isn’t really unclaimed definition
space (except for the tiny, that’s purely implementation-defined and
unclear in scope right now).

>>> that if the user community pick memorable names for useful subsets
>>> (similar to the R7RS-large Red, Orange, etc. but more differentiated)
>>> those subsets will become recognizable brands in their own right.
>
>> I think that creating these subsets is what we’re doing right now. We
>> *are* the user community that cares about finding subsets.
>
> Sure. It's just a question of who should decide the subsets: the
> authors of RnRS at publication time, or its users after the fact.

I think it should be done at publication-time; and only change from
Report to Report. Otherwise I people cannot take long term decisions
based on those subsets.

Changing the subsets later would also make it harder for new
implementations to join, because they would have to code against a
moving target.

> We can avoid publishing separate Small and Medium standards for R8RS.
> They can be the same document. This is a huge win IMHO - it's easiest
> to understand and verify the correctness of the standard if it's one
> document.

I think having it in one document would be a loss for the smaller
Schemes. However if R7RS-large then exists, it could be created by first
writing the small standards and then creating the larger ones by
extending the small documents and exporting the small ones as subsets of
the document.

(I have a mental image of an org-mode document with tags in my mind.
Collapse all the non-R8RS-tiny headlines and the document should still
be a coherent text — export only the chapters tagged as R8RS-tiny to get
the R8RS-tiny standard)

To really get there requires the assurance, though, that the small
standards are proper subsets of the larger ones. And for that we should
first have R7RS-large (or at least medium).

>> I still do not see this as prestige. It is a service to other users to
>> identify and provide the common tools that should be available.
>> It is what I as a user need.
>
> Prestige is universal - it's the basic currency of the economics of
> social status which underlies most human behavior.

While this is common, it is not valid for all people.

> "Scheme" is more
> prestigious than "Froz" because people trust Scheme whereas nobody
> knows what Froz is.

I chose to use Scheme, because of hygienic macros, because of being
standardized, because of having multiple implementations, and because I
enjoyed writing Scheme more than writing Fortran.

I chose Guile because it has similar activity as other Schemes (that was
a strict requirement; not betting on an in active project), because it
is big enough that I can implement any software I might want to write in
it, and because it is the official GNU extension language, which makes
it likely that it survives for longer.

The last point could be constructed as being about prestige, but the
reason is closer to the connection to guarantees I as user get from Free
Software ideals, which made it less likely that it would break those (as
Python did in-my-personal-gut-feeling when choosing to migrate to
GitHub).

How many people actually choose Scheme for prestige? For Haskell or Rust
I could understand that, but Scheme?

But maybe it’s also that we’re using the word "prestige" differently?
What does prestige mean for you?
signature.asc

Martin Rodgers

unread,
Mar 9, 2022, 2:47:51 PMMar 9
to scheme-re...@googlegroups.com, Lassi Kortela
On 09/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
> Am Mi., 9. März 2022 um 18:43 Uhr schrieb Martin Rodgers
> <mcro...@gmail.com>:
>
>> This isn't a zero-sum game, as your argument implies. Systems like
>> Larceny, Guile, Racket etc have existed for years. They all
>> demonstrate the ease of supporting multiple, divergemt languages
>> within the same Scheme system. Likewise, systems which support only
>> one report have also existed for years and continue to be used. I find
>> it suprising that you ignore this. I'm a little tired of pointing it
>> out, only for you to ignore it *again*.
>
> It should be noted that neither Larceny nor Guile, nor Racket support
> *any* of the Scheme reports in the sense that, say, GCC is aiming at
> supporting ISO C fully. The point is that Larceny, Guile, and Racket
> all have to make compromises due to the different languages they try
> to support at the same time.

Every Scheme I've used has diverged from every report, in some small
degree. I've always had to write *some* code for a specific system,
however small. R7RS helps with this in ways that previous reports
failed. E.g. cond-expand and include in both library declarations and
expressions. Scheme *systems* have helped with various features
outside the scope of a report, like the mapping of library names to
files. E.g. Larceny.

It should also be noted that there's at least one major schism in the
C community due to a standard. GNU C versions after 2.95 are a part of
that schism. You can't please all the programmers all the time. I may
have made that line already here.

> The situation is different with systems like Chibi or Chez, which
> successfully aim to support one standard fully.

That's why I test my code using Chibi *and* Larceny. My code runs too
slowly in Chibi to be practical, but its great for running the unit
tests. Larceny runs my code fast enough to be useful.

Incidently, I found even larger performance differences running some
of the Gabriel benchmarks. I'm still unsure what makes Chibi
underperform so badly. Perhaps someday I'll look at that more closely.

> I'm mentioning this because this may underlie Lassi's initial point of
> the search for a Scheme standard that attracts more implementations to
> support it fully in the GCC sense from my example above.

That's zero-sum thinking. Making R7RS more like R6RS won't increase
the number of R6RS systems. Making R7RS a superset of R6RS would break
a some existing code. The goal presumes that no such code exists and
won't break when R7RS Small is changed, nevermind code using the Red
and Tangerine editions.

Perhaps code using Large is fair game. This is why I'm writing my code
in strict R7RS Small plus SRFIs. No Large dependancies in my code, to
avoid exactly this problem.

So how might WG2 satisfy Lassi's goals? Adding support for the R6RS
library language? Won't that violate WG's self-consistancy goal?
There's a limit to how far R7RS can go, given the progress that has
alreay been made.

If Lassi wants to fork, that's their choice. If they do that, I wish
them well with that endeavour. This isn't a zero-sum game. WG2 can
then proceed while remaining consistant with the goals stated in its
charter.

Lassi Kortela

unread,
Mar 9, 2022, 3:01:24 PMMar 9
to Martin Rodgers, scheme-re...@googlegroups.com
> Making R7RS a superset of R6RS would break
> a some existing code. The goal presumes that no such code exists and
> won't break when R7RS Small is changed

If any such cases are found, it would be prudent to ensure the minimum
possible breakage.

If you're referring to the R6RS strictness ("portability", in the
language of that specification?) guarantee, it seems a R6RS+R7RS uniting
standard would have to make strictness an optional feature in order to
be widely adopted. Looking at the existing Scheme implementations, there
doesn't seem to be a clear preference for strict or lenient.

> Adding support for the R6RS
> library language? Won't that violate WG's self-consistancy goal?

Yes, it will. Self-consistency is kind of a weird goal to have for a
large standard IMHO. Common Lisp is notoriously inconsistent, but it's
large and useful. And it's still remarkably consistent for a spec of its
scale and sophistication.

John Cowan

unread,
Mar 9, 2022, 3:31:41 PMMar 9
to scheme-re...@googlegroups.com, Dr. Arne Babenhauserheide


On Wed, Mar 9, 2022 at 4:45 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
 
> Most of Scheme's features are easily factored into libraries, and both
> R6RS and R7RS have implicitly followed this pricinple. For example,
> dropping the (scheme complex) library in R7RS can yield an
> implementation without complex number support.

The problem here is the non-monotonicity of features, I think.


Say, I am writing a library (frob) that exports the frobnicate
procedure that frobnicates every Scheme value. If I want this library
to be fully portable and complete, it has to be able to frobnicate
also complex values.

The traditional Scheme mechanism for handling this has been to provide universal polymorphism when available, and otherwise provide monomorphic procedures only.  There are two exceptions to this: I/O and the numeric tower provide ad hoc polymorphism.  It is dangerous to reason generally on the basis of either of these special cases. 

Thus, it either has to important (scheme complex)
unconditionally or it imports (scheme complex) conditionally and
offers effectively two versions of frobnicate, one with and one
without complex number support and exporting the one that would be
supported by the implementation.

If it is the case that (frob e) where e is not a (generalized) complex number produces a non-real value, then you can't really avoid case 1, and the exception system takes over if e is in fact non-real.  By the same token, a system without (generalized) complex numbers that is asked to evaluate (sqrt -2) has to either signal an exception or return a specialized value such as NaN.

But if frobnication does not have this property, then case 2 is clearly better: there is more complexity for the implementer of frobnication but less for the consumer.  The (frobnicate-complex) procedure (which is not exposed) would be excluded on systems where complex numbers are not provided.  Note that the discrimination predicates for the numeric tower are always provided: that is, you can ask if a number is real or non-real even if non-real numbers are not supported.  This is not in general the case for non-numeric data types.
 
In the latter

case, writing the library becomes quite a hassle, especially when it
not only depends on complex number support but also on other optional
parts, probably leading to some combinatorial explosion.

As seems to often be true, I don't think the situation is as bad as you fear.

Dr. Arne Babenhauserheide

unread,
Mar 9, 2022, 4:24:06 PMMar 9
to scheme-re...@googlegroups.com, Martin Rodgers, Lassi Kortela

Lassi Kortela <la...@lassi.io> writes:

>> Adding support for the R6RS
>> library language? Won't that violate WG's self-consistancy goal?
>
> Yes, it will. Self-consistency is kind of a weird goal to have for a
> large standard IMHO.

Isn’t self-consistency the main reason for having RnRS instead of just
SRFIs?
signature.asc

Marc Nieper-Wißkirchen

unread,
Mar 9, 2022, 5:03:34 PMMar 9
to scheme-re...@googlegroups.com, Lassi Kortela
Am Mi., 9. März 2022 um 20:47 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:
>
> On 09/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
> > Am Mi., 9. März 2022 um 18:43 Uhr schrieb Martin Rodgers
> > <mcro...@gmail.com>:

> That's why I test my code using Chibi *and* Larceny. My code runs too
> slowly in Chibi to be practical, but its great for running the unit
> tests. Larceny runs my code fast enough to be useful.

Try running your Chibi code with a huge heap size. And by huge I mean
something like 10 GB. I have experienced great speed increases;
somehow the garbage collector (or the memory allocator under memory
constraints) is very slow in Chibi.

> That's zero-sum thinking. Making R7RS more like R6RS won't increase
> the number of R6RS systems. Making R7RS a superset of R6RS would break
> a some existing code. The goal presumes that no such code exists and
> won't break when R7RS Small is changed, nevermind code using the Red
> and Tangerine editions.

It will (hopefully) cause R6RS systems to support R7RS natively. And
will (hopefully) cause R7RS systems that are big enough to eventually
support the large language (e.g. have syntax-case) to support R6RS
natively as well. The idea is, of course, that the differences blur.

> So how might WG2 satisfy Lassi's goals? Adding support for the R6RS
> library language? Won't that violate WG's self-consistancy goal?
> There's a limit to how far R7RS can go, given the progress that has
> alreay been made.

One can make a case for why it makes sense to include both the R6RS
and the R7RS library syntax. (And even if not, I wouldn't really call
it a question of self-consistency, but more or redundancy, which is
related, of course.)

Marc

Martin Rodgers

unread,
Mar 9, 2022, 5:46:32 PMMar 9
to Lassi Kortela, scheme-re...@googlegroups.com
On 09/03/2022, Lassi Kortela <la...@lassi.io> wrote:
>> Making R7RS a superset of R6RS would break
>> a some existing code. The goal presumes that no such code exists and
>> won't break when R7RS Small is changed
>
> If any such cases are found, it would be prudent to ensure the minimum
> possible breakage.

Agreed. AIUI, this is how R7RS is going. I imagine WG2 could add
support for square brackets to the parser. I understand why WG1 didn't
do that, but that's exactly the kind of R6RS feature that could be
safely added to R7RS without breaking strictly conforming R5RS and
R7RS Small code.

> If you're referring to the R6RS strictness ("portability", in the
> language of that specification?) guarantee, it seems a R6RS+R7RS uniting
> standard would have to make strictness an optional feature in order to
> be widely adopted. Looking at the existing Scheme implementations, there
> doesn't seem to be a clear preference for strict or lenient.

I was thinking more of things like the library syntax. This is one of
the first things to break when I began rewriting thousands of lines of
code, converting it from R6RS to R7RS. Every single library had to be
modified just for the syntax. The transition from R5RS to R6RS was
never that painful, but could've been made easier if R6RS had include.
Converting the other way would also be painful. So I stopped writing
code in Scheme for a decade.

Sure, I could've defined include using syntax-case, but it made more
sense to use the library syntax. It was designed for that job.
Previously, in R5RS, I had to cope with the include/load problem for
Scheme compilers. Interpreters could use load, and still can, but
compilers benefit from include. They benefit even more from libraries.

R7RS has both include *and* libraries. Better yet, it has expression
and library declaration cond-expand. Can we portably extend R6RS
library syntax to support cond-expand? I don't see how.

So I contend that the two library languages are both useful but
different, and different enough to make translating from one to the
other hard. I also contend that the R7RS library language is more
useful than the R6RS library language. Would the former be more useful
still if it supported the R6RS subversion feature? Perhaps. I really
don't know. I never used that feature in my code. I just didn't have a
problem that it solved. I still don't.

However, I'll concede that this is a subjective viewpoint. I'll accept
that the experience of some R6RS users may be different, and contrary.
That's why I'm happy to see that R6RS has a community using it. That
makes the effort of creating and maintaining support for the language
worthwhile. I'd hate to see any of that wasted. I used four Schemes
supporting R6RS, and found the experience writing and sharing code
between those systems easy.

So I'm happy to see many of those R6RS features become available in
R7RS. However, I still have reservations about syntax-case in R7RS. In
R6RS, the library language makes it easy to share code defined in one
library and then used in other libraries in syntax-case expressions.
I've to understand how this might be done in R7RS. That is, R7RS still
lacks library syntax to talk importing for phase n+m. I believe this
can be done consistantly with existing library syntax, but either WG2
has yet to discuss the details or I've somehow missed it.

>> Adding support for the R6RS
>> library language? Won't that violate WG's self-consistancy goal?
>
> Yes, it will. Self-consistency is kind of a weird goal to have for a
> large standard IMHO. Common Lisp is notoriously inconsistent, but it's
> large and useful. And it's still remarkably consistent for a spec of its
> scale and sophistication.

Yes, Kent Pitman wrote about that. I remember Guy Steele's many
"historical notes" explaining those inconsistancies. I also appreciate
his notes on implementation issues. I have both 1st and 2nd editions
of his books on Common Lisp, BTW, and would frequently read them very
carefully.

By the late 1990s and early 2000s, I began to scrutinize Scheme
reports and then SRFIs. Nevermind many hundreds of CS papers over the
last couple of decades. It's a joy to read Scheme code, recognise the
algorithms, and study their implementations.

However, no language definition is without critics. You can't please

Martin Rodgers

unread,
Mar 9, 2022, 6:41:54 PMMar 9
to scheme-re...@googlegroups.com, Lassi Kortela
On 09/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
> Am Mi., 9. März 2022 um 20:47 Uhr schrieb Martin Rodgers
> <mcro...@gmail.com>:
>>
>> On 09/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>> > Am Mi., 9. März 2022 um 18:43 Uhr schrieb Martin Rodgers
>> > <mcro...@gmail.com>:
>
>> That's why I test my code using Chibi *and* Larceny. My code runs too
>> slowly in Chibi to be practical, but its great for running the unit
>> tests. Larceny runs my code fast enough to be useful.
>
> Try running your Chibi code with a huge heap size. And by huge I mean
> something like 10 GB. I have experienced great speed increases;
> somehow the garbage collector (or the memory allocator under memory
> constraints) is very slow in Chibi.

Ahh, my largest heapsize tests were two orders of magnitude too small
to reveal the advantages of this option. ;) That greatly helps with
some programs but not noticably for others. Anyway, thanks.

>> That's zero-sum thinking. Making R7RS more like R6RS won't increase
>> the number of R6RS systems. Making R7RS a superset of R6RS would break
>> a some existing code. The goal presumes that no such code exists and
>> won't break when R7RS Small is changed, nevermind code using the Red
>> and Tangerine editions.
>
> It will (hopefully) cause R6RS systems to support R7RS natively. And
> will (hopefully) cause R7RS systems that are big enough to eventually
> support the large language (e.g. have syntax-case) to support R6RS
> natively as well. The idea is, of course, that the differences blur.

It may make it easier for some larger systems. I can't comment on the
time required to add that code. I don't have that experience. I can
only note that Larceny's library support for R7RS is built on a large
SRFI collection, and that is built on the earlier support for R6RS and
an older SRFI collection. Guile's support for R6RS and R7RS looks a
little different, as my impression is that there's more library code
written in Guile Scheme than either R6RS or R7RS, but I really need to
study Guile's libraries more.

>> So how might WG2 satisfy Lassi's goals? Adding support for the R6RS
>> library language? Won't that violate WG's self-consistancy goal?
>> There's a limit to how far R7RS can go, given the progress that has
>> alreay been made.
>
> One can make a case for why it makes sense to include both the R6RS
> and the R7RS library syntax. (And even if not, I wouldn't really call
> it a question of self-consistency, but more or redundancy, which is
> related, of course.)

This is exactly what Guile and Larceny do. Racket also supports
multiple library languages. Chibi only supports R7RS so far. All the
above Schemes support features beyond any Scheme report. So I think it
may depend on the goals of the implementers and maintainers. Who is
adding R7RS support to Racket? (Rhetorical question.) Who will add
R6RS support to Chibi? (Another rhetorical question.)

This takes time and effort. The same resources could also be spent
creating another Scheme. There are advantages to pooling those
resources, like sharing of code. There are also advantages to
independant implementations, like freedom of strategies. I think these
are choices for implementers to make, not the language designers.

John Cowan

unread,
Mar 9, 2022, 8:54:45 PMMar 9