I'm worried

[Vincent Manis]

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]

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]

> 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]

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

[Marc Nieper-Wißkirchen]

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]

> 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]

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]

And even that is not a guarantee for success.

[Lassi Kortela]

> 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]

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]

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]

> 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]

> 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]

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.

[Lassi Kortela]

> (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]

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.

[Lassi Kortela]

> 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]

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]

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]

> 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]

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]

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]

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]

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]

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]

> 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]

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]

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]

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]

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]

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]

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.