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.

[Lassi Kortela]

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

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?

[Martin Rodgers]

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]

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

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]

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?

[Marc Nieper-Wißkirchen]

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]

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]

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]

On Tue, Mar 8, 2022 at 6:52 PM Vincent Manis <vman...@gmail.com> wrote:

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.

I agree entirely.  I've remained silent (except to correct factual errors) up to now in hopes that the discussion would stop proliferating and come to either some definite conclusions or silence.  But that seems unlikely, so I'm going to speak up now.

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

I think I understand why you say this.  But the fact is that we didn't know who the editors of R7RS-small (Shinn, Cowan, Gleckler) would be until quite late in the process, and only one of them is a Scheme implementor (whether you consider Chibi "leading" is up to you).  Editing is a skill quite separate from programming, and there is no particular reason why anyone should combine them.

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

Such lists do in fact exist: in the <https://github.com/johnwcowan/r7rs-work> repo there are the pages ErrorSituations.md and ItIsAnError.md.  These need to be merged and cleaned up, and then R7RS-small needs to be scrutinized for other cases that don't use the phrase "it is an error", of which there are many.

But such a list would be a work product, not something that can be specified in advance.

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

What I would like to see is something like this:

Medium is renamed "R7RS-large Foundation Libraries", or some such name.  It is created by a (self-appointed) subcommittee of WG2 (which means that the Steering Committee need not be involved), and then WG2 (i.e. the Scheme community) will decide whether to incorporate it into R7RS-large by a vote.  If that vote fails, then the Foundation Libraries will be voted on individually.

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

I don't know enough to speak to that.

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

Here's my proposal on that:  A library is a candidate for the Foundation Libraries if it cannot be implemented using only Small and the other Foundation Libraries.  So SRFI 1 is not a Foundation Library, whereas syntax-case is.  If library (a) can be implemented using (b) and (b) can be implemented using (a), it will be necessary to make a case-by-case decision about whether (a) or (b) is a Foundation Library.

[Vincent Manis]

Reposted because I'm still having trouble learning to use Reply All :)

-------- Forwarded Message --------

Subject:	Re: [scheme-reports-wg2] I'm worried
Date:	Wed, 9 Mar 2022 18:15:47 -0800
From:	Vincent Manis <vma...@telus.net>
To:	John Cowan <co...@ccil.org>

On 2022-03-09 5:54 p.m., John Cowan wrote, quoting me:

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

I think I understand why you say this.  But the fact is that we didn't know who the editors of R7RS-small (Shinn, Cowan, Gleckler) would be until quite late in the process, and only one of them is a Scheme implementor (whether you consider Chibi "leading" is up to you).  Editing is a skill quite separate from programming, and there is no particular reason why anyone should combine them.

This makes sense to me. I guess I want to stop talking about editors and start talking about contributors. We need to identify people who are actually going to do this work. Editing does indeed come later, though in this case, since I think much of the development work has already been done, it might come sooner than one might think.

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

Such lists do in fact exist: in the <https://github.com/johnwcowan/r7rs-work> repo there are the pages ErrorSituations.md and ItIsAnError.md.  These need to be merged and cleaned up, and then R7RS-small needs to be scrutinized for other cases that don't use the phrase "it is an error", of which there are many.

But such a list would be a work product, not something that can be specified in advance.

Agreed. But the need to address this must be in the group's charter.

What I would like to see is something like this:

Medium is renamed "R7RS-large Foundation Libraries", or some such name.  It is created by a (self-appointed) subcommittee of WG2 (which means that the Steering Committee need not be involved), and then WG2 (i.e. the Scheme community) will decide whether to incorporate it into R7RS-large by a vote.  If that vote fails, then the Foundation Libraries will be voted on individually.

Agreed.

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

I don't know enough to speak to that.

There are the existing SRFIs that improve I/O. Some comments have been made about the R6RS condition system. There may be others. As I said in an earlier post, it's essential that this effort not waste time developing facilities that won't be included in Large.

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

Here's my proposal on that:  A library is a candidate for the Foundation Libraries if it cannot be implemented using only Small and the other Foundation Libraries.  So SRFI 1 is not a Foundation Library, whereas syntax-case is.  If library (a) can be implemented using (b) and (b) can be implemented using (a), it will be necessary to make a case-by-case decision about whether (a) or (b) is a Foundation Library.

I could definitely live with that.

My key point is to limit the scope of this project so that it can be completed expeditiously and is a significant contribution to the Large process.

-- vincent

[Arthur A. Gleckler]

On Wed, Mar 9, 2022 at 5:54 PM John Cowan <co...@ccil.org> wrote:

 

I think I understand why you say this.  But the fact is that we didn't know who the editors of R7RS-small (Shinn, Cowan, Gleckler) would be until quite late in the process, and only one of them is a Scheme implementor (whether you consider Chibi "leading" is up to you).  Editing is a skill quite separate from programming, and there is no particular reason why anyone should combine them.

There were two of us, actually, depending on how you define implementor.  I haven't initiated a popular Scheme implementation, but I've been working on my own one since before R7RS Small.  I made non-trivial contributions to MIT Scheme, including bits of the compiler, the debugger, and the runtime system.

  

What I would like to see is something like this:

Medium is renamed "R7RS-large Foundation Libraries", or some such name.  It is created by a (self-appointed) subcommittee of WG2 (which means that the Steering Committee need not be involved), and then WG2 (i.e. the Scheme community) will decide whether to incorporate it into R7RS-large by a vote.  If that vote fails, then the Foundation Libraries will be voted on individually.

That sounds reasonable, although I thought that some people were thinking of Medium as dealing with non-library issues in Scheme, e.g. dealing with all inconsistencies with R6RS and tightening up where exceptions must be thrown.

[John Cowan]

On Wed, Mar 9, 2022 at 10:34 PM Arthur A. Gleckler <a...@speechcode.com> wrote:

 

There were two of us

Sorry, I tend to forget that.

That sounds reasonable, although I thought that some people were thinking of Medium as dealing with non-library issues in Scheme, e.g. dealing with all inconsistencies with R6RS and tightening up where exceptions must be thrown.

Oh, absolutely.  Probably there will need to be an R6RS committee and a cleanup committee as well.

[Lassi Kortela]

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

Maybe we're mixing up two things:

1. Self-consistent semantics.

2. Self-consistent style. (As in, aesthetics.)

Common Lisp has self-consistent semantics to an impressive degree, but
not style. E.g. the "nth" and "elt" functions have overlapping purpose
and inconsistent naming. The "intersection" function only works on
lists, though many of the sequence function work on all types of
sequences. There are tons of examples like this.

I expect R7RS-large, as planned, to be self-consistent in the same way
as Common Lisp: semantics, not style. That's a good outcome to be proud
of, and to be expected of any language that size.

IMHO any language standard bigger than R5RS is going to be document of a
"living language", where bits of the language come and go as the culture
of usage develops over the years.

[Marc Nieper-Wißkirchen]

Am Do., 10. März 2022 um 00:41 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 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.

From my experience, first-class continuations are also a quite costly
thing in Chibi. Are you using them in procedures that are called very
often?

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

Assuming that we have found a minimal union of R6RS and R7RS (related
to my "reconciliation" post, not to "Medium", which would be bigger),
I wouldn't expect every R7RS (small) system to support it (eventually)
as the union would have to be at least as large as R6RS. R7RS-Small
was created to fill a niche that R6RS left open and that niche won't
be gone. The union project would be an offer to all systems of the
scope of at least R6RS.

[Lassi Kortela]

> Agreed. AIUI, this is how R7RS is going. I imagine WG2 could add
> support for square brackets to the parser.

I didn't realize square bracket support is mandatory in R6RS. Many
lispers don't like them, and in at least Emacs Lisp and Clojure they
make vectors. In Arc (PG's Lisp) they make closures.

The reason I suggested renaming R7RS-large and/or -medium to R8RS is
that it's confusing if they make changes to the lexical syntax (among
other fundamentals) of an earlier document bearing the same RnRS number.

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

Couldn't agree more! The different library syntax is the deal breaker
due to which most people simply won't write libraries that run on all
the major implementations.

If the library syntax is compatible, people can send portability patches
to each other's libraries simply by adding some cond-expand's.

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

Marc has a plan for specifying `define-library` as an extension of
`library`.

> However, I still have reservations about syntax-case in R7RS.

You're not the only one. I'm skeptical we can convince all implementers
to add syntax-case; people have tried. In the Medium I propose it would
be an optional module. There's a lot of useful R6RS code that doesn't
rely on syntax-case macros, so that code would still be portable.

> R7RS still lacks library syntax to talk importing for phase n+m.

I'm under the impression that implicit phasing has completely won over
explicit phasing in R6RS. If so, any Medium or Large standard we're
making could use only implicit phasing.

> However, no language definition is without critics. You can't please
> all the programmers all the time.

Indeed. I applaud Common Lisp for pursuing compatibility over purity.

[Marc Nieper-Wißkirchen]

Am Mi., 9. März 2022 um 23:46 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:

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

No one has probably used the library versioning system of R6RS to its
fullest extent. But basic versioning is an important feature. Unless
we add versioning, (scheme base) would be either fixed forever by
what's in R7RS-small or future reports would not be backward
compatible with R7RS-small.

But whether to add versioning information to library names or not is
orthogonal to the library definition syntax anyway, I think.

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

From what you wrote earlier citing your own Scheme implementations,
your reservations about syntax-case seem to come from the fact that it
is a procedural macro system so that the full Scheme language is
available when writing transformers. This and the phasing issues you
mention are not specific to syntax-case; the same would be true for ER
macros.

What still has to be discussed by WG2 is whether

(a) implicit phasing is used
(b) explicit phasing is used
(c) implicit or explicit phasing is allowed.

R6RS couldn't agree on either implicit or explicit phasing, so they
choose (c), which IMO, was the worst outcome.

Should WG2 choose (a), no phasing annotations are needed. Should WG2
choose (b) or (c), the R6RS phasing annotations can be incorporated
into the R7RS library syntax mutatis mutandis, so I don't see a big
problem here.

Marc

[Lassi Kortela]

> From my experience, first-class continuations are also a quite costly
> thing in Chibi.

IMHO tail calls, not continuations, are the defining control feature of
Scheme. But I won't pursue that heresy here :p

>> Who is adding R7RS support to Racket?

https://pkgd.racket-lang.org/pkgn/search?q=r7rs

> Assuming that we have found a minimal union of R6RS and R7RS (related
> to my "reconciliation" post, not to "Medium", which would be bigger),
> I wouldn't expect every R7RS (small) system to support it (eventually)
> as the union would have to be at least as large as R6RS. R7RS-Small
> was created to fill a niche that R6RS left open and that niche won't
> be gone. The union project would be an offer to all systems of the
> scope of at least R6RS.

Subsets of R6RS are still useful. As long as all the major
implementations support both `library` and `define-library` and all the
lexical syntax, the remaining parts of R6RS can be added piecemeal as
libraries.

I expect a process where the implementer says "That library is ugly, no
way I'll add that to my Scheme!" Then users keep complaining they can't
run some code for a year or two, and finally the implementer caves in
and says "oh well". That's how Scheme portability will gradually improve :D

[Marc Nieper-Wißkirchen]

This is just my opinion about the idea of "Medium", but such a static
decision rule falls too short (by far). The idea of "Medium" emerged
ultimately from Daphne's letter about improving the R7RS Large
process. One issue that was raised is self-consistency, e.g. the order
of arguments in fold-like procedures. If "Medium" wants to help
enforcing such kinds of consistency, it is important that there's
something about generic fold procedures it although fold could be
implemented on top of the rest (and would thus fail this static
decision rule). Another example would be what glue to use between
different sequence types. So far, it seems that R7RS Large builds on
generators for that (I don't think that it is a good idea at all - but
that's as irrelevant as Carthago for my point here), so we have
...->generator and generator->... procedures scattered everywhere. It
thus may make sense to codify what a generator-aware abstract data
type is in the "Medium" document.

In other words, "Medium" could also become a guideline for library
writers for the large language; but for that, "Medium" would have to
be more than just a bare bunch of libraries stripped down until no
redundancy is left.

[Dr. Arne Babenhauserheide]

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

>>> 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?
>
> Maybe we're mixing up two things:
>
> 1. Self-consistent semantics.
>
> 2. Self-consistent style. (As in, aesthetics.)

Self-consistent style is not just aesthetics. It’s ease of learning and using.

> Common Lisp has self-consistent semantics to an impressive degree, but
> not style. E.g. the "nth" and "elt" functions have overlapping purpose
> and inconsistent naming. The "intersection" function only works on
> lists, though many of the sequence function work on all types of
> sequences. There are tons of examples like this.

That sounds horrible.

> IMHO any language standard bigger than R5RS is going to be document of
> a "living language", where bits of the language come and go as the
> culture of usage develops over the years.

Python is a lot bigger than R5RS, and it provides self-consistent style.
It is one of its largest strengths: If you go into a new shipped
library, it usually works just like you expect it to work.

Scheme might not get as far in consistency, but I think it is wrong to
just discard self-consistent style out of hand.

[Daphne Preston-Kendal]

On 10 Mar 2022, at 08:05, Lassi Kortela <la...@lassi.io> wrote:

>> Agreed. AIUI, this is how R7RS is going. I imagine WG2 could add
>> support for square brackets to the parser.
>
> I didn't realize square bracket support is mandatory in R6RS. Many lispers don't like them, and in at least Emacs Lisp and Clojure they make vectors. In Arc (PG's Lisp) they make closures.

With basic customizable read syntax, we could leave this decision up to the user, as well as lay some groundwork to support reader syntax for custom record-types etc, if people want that:
<https://gitlab.com/dpk/presrfis/-/blob/master/bracket-shapes.md>

(Strawman proposal, but one that’s been rattling around in my head for a few months.)


Daphne

[Marc Nieper-Wißkirchen]

Am Do., 10. März 2022 um 09:40 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:

A few quick comments:

(1) The strawman proposal will only work with syntactic forms like
`include' and not with the `read' procedure because you refer to the
lexical environment of the form that actually read.
(2) I'm not sure why you want `disallow-brackets', etc. to be macros;
would it make more sense if they were procedures (but possibly defined
at the meta level)?
(3) It's not hygienic what you propose; `disallow-brackets' could be a
renamed identifier, but you just have a symbol to refer to it.
(4) I think the better answer is: If you don't like square brackets,
don't use them. Provide a standardized reader flag (like #!r6rs) that
enables a standardized common lexical syntax of R6RS and R7RS
including square brackets.

[Lassi Kortela]

> (4) I think the better answer is: If you don't like square brackets,
> don't use them. Provide a standardized reader flag (like #!r6rs) that
> enables a standardized common lexical syntax of R6RS and R7RS
> including square brackets.

Right. Requiring "#!r6rs" isn't much of a stretch. I'm in favor of this.

[Lassi Kortela]

> With basic customizable read syntax, we could leave this decision up to the user, as well as lay some groundwork to support reader syntax for custom record-types etc, if people want that:
> <https://gitlab.com/dpk/presrfis/-/blob/master/bracket-shapes.md>

Customizable read syntax features prominently in Common Lisp, and people
virtually always abuse it.

Lexical syntax is the basis of interchange (essentially, it's the file
format). Whenever people have custom read syntax, static analysis and
indexing tools can't read those files. Editors often don't know how to
work with them either. And often enough, neither do humans...

CL feeds custom read syntax into an arbitrary procedure (i.e. readers
are defined using a Turing complete, non-reversible language) so there's
no way even in principle for tools reading the file to figure out what
is going on.

(I'll omit my usual rant about how text syntax is a dead end to begin
with :-)

For Scheme, I'd suggest "#!r6rs" or "#!square-brackets" and nothing more
complex.

As a separate issue, a lot of good design went into CL's reader. It's a
good basis for a reconfigurable reader. Putting a reconfigurable reader
front and center of a language syntax is a bad idea, but it's a good
idea to provide one for user programs to read files, e.g. for
implementing a Clojure or ELisp interpreter in Common Lisp.

I'd like to distill a common basis out of most of the extant
S-expression flavors, and design a reconfigurable reader that can be
made to handle all of them. The s-expressions.org organization /
#s-expressions IRC channel on libera would be a good place for such
work. But if you can beat me to it, by all means do so.
S-expressions.org is owned by Steve Wiley.

[Per Bothner]

On 3/9/22 23:05, Lassi Kortela wrote:
> I didn't realize square bracket support is mandatory in R6RS. Many lispers don't like them, and in at least Emacs Lisp and Clojure they make vectors. In Arc (PG's Lisp) they make closures.

In Kawa square brackets make vectors:
[e1 ... en] is equivalent to (vector e1 ... en) except the result is immutable.
The sub-expressions e1 ... en are evaluated, not literal.
--
--Per Bothner
p...@bothner.com http://per.bothner.com/

[Marc Nieper-Wißkirchen]

Am Do., 10. März 2022 um 10:36 Uhr schrieb Per Bothner <p...@bothner.com>:

> On 3/9/22 23:05, Lassi Kortela wrote:
> > I didn't realize square bracket support is mandatory in R6RS. Many lispers don't like them, and in at least Emacs Lisp and Clojure they make vectors. In Arc (PG's Lisp) they make closures.
>
> In Kawa square brackets make vectors:
> [e1 ... en] is equivalent to (vector e1 ... en) except the result is immutable.
> The sub-expressions e1 ... en are evaluated, not literal.

How does

(let ((vector list))
[e1 ... en])

behave?

In any case, Scheme systems have always added lexical syntax
extensions and will certainly also do so in the future but I don't
think that it is a big issue for standardization efforts; it's easy to
specify a way how to switch a reader into standards mode and as easy
to add such a flag to an individual Scheme's code basis.

[Per Bothner]

On 3/10/22 01:49, Marc Nieper-Wißkirchen wrote:
> Am Do., 10. März 2022 um 10:36 Uhr schrieb Per Bothner <p...@bothner.com>:
>
>> On 3/9/22 23:05, Lassi Kortela wrote:
>>> I didn't realize square bracket support is mandatory in R6RS. Many lispers don't like them, and in at least Emacs Lisp and Clojure they make vectors. In Arc (PG's Lisp) they make closures.
>>
>> In Kawa square brackets make vectors:
>> [e1 ... en] is equivalent to (vector e1 ... en) except the result is immutable.
>> The sub-expressions e1 ... en are evaluated, not literal.

[e1 ... e2] is actually syntactic (read-time) sugar for as ($bracket-list$ e1 ... en)
The (kawa base) library defines $bracket-list$ as a syntax for (constant-vector e1 ... en).

Well, that is a slight simplification.
Brackets are also used for range expressions: https://www.gnu.org/software/kawa/Ranges.html
For example [2 <: 7] is functionally equivalent to [2 3 4 5 6] (but more compact).

So the actual definition is:

(define-syntax $bracket-list$
(syntax-rules (<: <=: >: >=:)
((_ x <: y) (gnu.kawa.functions.RangeUtils:upto x 1 y #f))
((_ x <=: y) (gnu.kawa.functions.RangeUtils:upto x 1 y #t))
((_ x >: y) (gnu.kawa.functions.RangeUtils:downto x -1 y #f))
((_ x >=: y) (gnu.kawa.functions.RangeUtils:downto x -1 y #t))
((_ x by: step <: y) (gnu.kawa.functions.RangeUtils:upto x step y #f))
((_ x by: step <=: y) (gnu.kawa.functions.RangeUtils:upto x step y #t))
((_ x by: step >: y) (gnu.kawa.functions.RangeUtils:downto x step y #f))
((_ x by: step >=: y) (gnu.kawa.functions.RangeUtils:downto x step y #t))
((_ x <:) (gnu.kawa.functions.RangeUtils:valueOfUnbounded x 1))
((_ x by: step) (gnu.kawa.functions.RangeUtils:valueOfUnbounded x step))
((_ x by: step size: sz) (gnu.kawa.functions.RangeUtils:bySize x step sz))
((_ x size: sz) (gnu.kawa.functions.RangeUtils:bySize x 1 sz))
((_ <:) (gnu.lists.Range$IntRange 0 1 -2))
((_ >:) (gnu.lists.Range$IntRange 0 -1 -2))
((_ . args) (constant-vector . args))))

> How does
>
> (let ((vector list))
> [e1 ... en])
>
> behave?

From the above, it follows that redefining vector (or for that matter constant-vector)
does not change the result. However:

(let (($bracket-list$ list)) [4 5 6]) => (4 5 6) ; a list

[Marc Nieper-Wißkirchen]

Thanks for the quick and detailed response, Per. So [...] in Kawa is
reader syntax that works exactly like the abbreviations for quote,
unquote, etc. in standard Scheme.

> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/5ca9bd7c-4d5d-d459-87c6-647278128f5f%40bothner.com.

[Martin Rodgers]

On 10/03/2022, John Cowan <co...@ccil.org> wrote:

> Here's my proposal on that: A library is a candidate for the Foundation
> Libraries if it cannot be implemented using only Small and the other
> Foundation Libraries. So SRFI 1 is not a Foundation Library, whereas
> syntax-case is. If library (a) can be implemented using (b) and (b) can be
> implemented using (a), it will be necessary to make a case-by-case decision
> about whether (a) or (b) is a Foundation Library.

I fully support this proposal. Thank you.

[Martin Rodgers]

On 10/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> From my experience, first-class continuations are also a quite costly
> thing in Chibi. Are you using them in procedures that are called very
> often?

See the Gabriel benchmarks. I expect Larceny to perform well, but
Guile also performs better than Chibi. However, this isn't relevant to
WG2. I suggest we continue this by email.

> Assuming that we have found a minimal union of R6RS and R7RS (related
> to my "reconciliation" post, not to "Medium", which would be bigger),
> I wouldn't expect every R7RS (small) system to support it (eventually)
> as the union would have to be at least as large as R6RS. R7RS-Small
> was created to fill a niche that R6RS left open and that niche won't
> be gone. The union project would be an offer to all systems of the
> scope of at least R6RS.

I fully support John's Foundation Libraries proposal.

[Daphne Preston-Kendal]

On 10 Mar 2022, at 02:54, John Cowan <co...@ccil.org> wrote:

> Here's my proposal on that: A library is a candidate for the Foundation Libraries if it cannot be implemented using only Small and the other Foundation Libraries. So SRFI 1 is not a Foundation Library, whereas syntax-case is. If library (a) can be implemented using (b) and (b) can be implemented using (a), it will be necessary to make a case-by-case decision about whether (a) or (b) is a Foundation Library.

Could this be amended to also exclude things that *would* be implementable in small if small had an FFI? So socket libraries and OS process control etc. are also the province of Large rather than Medium.

I’m also not entirely happy with the name ‘Foundation Library’. Not everything we will work on will be a library. (Reader syntax may be included, for example, if we want to adopt keyword datums or support square brackets for R6RS compatibility.)


Daphne

[Lassi Kortela]

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

In Common Lisp, everything is multiple-value-aware since the language
throws aware all other values except the primary (i.e. first) value
unless you capture all of them with multiple-value-bind or a few of the
other multiple-value-aware special operators.

Scheme doesn't guarantee the above? Should it?

[Marc Nieper-Wißkirchen]

Am Do., 10. März 2022 um 12:22 Uhr schrieb Lassi Kortela <la...@lassi.io>:
>
> > (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.)

This was just an example; I didn't intend to incite a discussion about
multiple values.

> In Common Lisp, everything is multiple-value-aware since the language
> throws aware all other values except the primary (i.e. first) value
> unless you capture all of them with multiple-value-bind or a few of the
> other multiple-value-aware special operators.
>
> Scheme doesn't guarantee the above? Should it?

It doesn't. And it shouldn't because this would hide too many typing errors.

Besides, it wouldn't solve the issue I raised in the example above:

(define (log proc)
(lambda args
(display "Enter procedure.\n")
(let ((res (apply proc args)))
(display "Leave procedure.\n")
res)))

This procedure is not multiple-value aware. Even with the CL model, it
wouldn't be.

What you would need is "multiple values" being a first-class concept.
That's true for Chibi, for example, but not true for the general
Scheme implementation, where it may have performance impacts.

[Marc Nieper-Wißkirchen]

Am Do., 10. März 2022 um 12:02 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
>

I second this objection by Daphne (regardless of my other objection
that I think that John's proposal would narrow "Medium" so much that
it would fail to achieve why it was initially launched). Another
non-library feature besides lexical syntax is evaluation semantics,
e.g. in the context of delimited continuations. The term "library" or
"module" is possibly a bit overworked. While the Scheme library system
solves many portability and modularity questions, it's far from a
solution for everything.

[Dr. Arne Babenhauserheide]

When you add a syntax element to the base-language, you take it out of
the elements, developers can use without risky side-effects.

If [ ] as ( ) is in r7rs-medium, then it will be used in lots of
standard code (as racket shows). Is the advantage of brackets-as-parens
bigger than the disadvantage from preventing custom treatment of
brackets?

I like the minimalism of Scheme syntax a lot, and [ ] are already
strange in that regard in r6rs. Having a default way to activate that
would not hurt much, I think. Having it [ ] as ( ) active by default and
having to disable it would pollute the core language with something that
*can* be taken away.

[John Cowan]

On Thu, Mar 10, 2022 at 2:40 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

 

> Here's my proposal on that:  A library is a candidate for the Foundation Libraries if it cannot be implemented using only Small and the other Foundation Libraries.  So SRFI 1 is not a Foundation Library, whereas syntax-case is.  If library (a) can be implemented using (b) and (b) can be implemented using (a), it will be necessary to make a case-by-case decision about whether (a) or (b) is a Foundation Library.

This is just my opinion about the idea of "Medium", but such a static
decision rule falls too short (by far). The idea of "Medium" emerged
ultimately from Daphne's letter about improving the R7RS Large
process. One issue that was raised is self-consistency, e.g. the order
of arguments in fold-like procedures. If "Medium" wants to help
enforcing such kinds of consistency, it is important that there's
something about generic fold procedures it although fold could be
implemented on top of the rest (and would thus fail this static
decision rule).

The static decision rule applies to libraries or quasi libraries, not to individual procedures.  The fold question is one of cleanup, which I didn't discuss above.

Another example would be what glue to use between
different sequence types. So far, it seems that R7RS Large builds on
generators for that (I don't think that it is a good idea at all - but
that's as irrelevant as Carthago for my point here), so we have
...->generator and generator->... procedures scattered everywhere. It
thus may make sense to codify what a generator-aware abstract data
type is in the "Medium" document.

The point of the "integer as digit generator" example is that any data structure can underlie a generator, or indeed none at all, as in SRFI 194.

[John Cowan]

On Thu, Mar 10, 2022 at 6:02 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:

Could this be amended to also exclude things that *would* be implementable in small if small had an FFI? So socket libraries and OS process control etc. are also the province of Large rather than Medium.

I'll have to think about that further.  I am not happy with it, but I don't yet know quite why.  It's a more complex situation than other bridged implementations because it's two-dimensional: there's not just the implementation, there's also the OS (or equivalent like the JVM).  My intuitive response is "Not unless Medium [etc.] provides an FFI as well."

I’m also not entirely happy with the name ‘Foundation Library’. Not everything we will work on will be a library. (Reader syntax may be included, for example, if we want to adopt keyword datums or support square brackets for R6RS compatibility.)

A cocky novice once said to Stallman: "I can guess why the editor is called Emacs, but why is the justifier called Bolio?" Stallman replied forcefully, "Names are but names. `Emack & Bolio's` is the name of a confectionary shop in Boston-town. Neither of these men had anything to do with the software."

His question answered, yet unanswered, the novice turned to go, but Stallman called to him, "Neither Emack nor Bolio had anything to do with the ice cream shop, either."

This is known as the ice-cream koan.

But seriously, I am fine with dropping the word "Libraries".

[Vincent Manis]

On 2022-03-10 8:32 p.m., John Cowan wrote:

A cocky novice once said to Stallman: "I can guess why the editor is called Emacs, but why is the justifier called Bolio?" Stallman replied forcefully, "Names are but names. `Emack & Bolio's` is the name of a confectionary shop in Boston-town. Neither of these men had anything to do with the software."

His question answered, yet unanswered, the novice turned to go, but Stallman called to him, "Neither Emack nor Bolio had anything to do with the ice cream shop, either."

I was told by someone who had worked for them that the now-defunct CGI/animation firm Rhythm And Hues had two major in-house applications, named “rhythm” and “hues” respectively. They built a third, and named it “and”.

But seriously, I am fine with dropping the word "Libraries".

Perhaps the project result can be called “Scheme: Foundation Language and Libraries”.

-- vincent

[John Cowan]

On Thu, Mar 10, 2022 at 3:56 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

 

(4) I think the better answer is: If you don't like square brackets,
don't use them. Provide a standardized reader flag (like #!r6rs) that
enables a standardized common lexical syntax of R6RS and R7RS
including square brackets.

While superficially plausible, that doesn't seem to meet the real objection, which is that some people think that square brackets make code more readable and should be allowed (and have a set of recommendations for when they should and should not be used), whereas others think they make code less readable and should be disallowed.  This conflict is isomorphic to the case-sensitive/insensitive disagreement and will, I believe, end up being resolved in the same way.

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAEYrNrQ_ZuRNBmLa1-%2B8eAhgWy_4gsUr9SySuwJuC8CYdKF1XQ%40mail.gmail.com.

[Alex Shinn]

On Thu, Mar 10, 2022 at 8:41 AM Martin Rodgers <mcro...@gmail.com> wrote:
>
> 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.)

https://github.com/lexi-lambda/racket-r7rs

R7RS-small is really quite easy to support for any reasonable implementation.

> Who will add R6RS support to Chibi? (Another rhetorical question.)

I'm happy to accept patches which improve R6RS operability without
significant increases to the core size. syntax-case and identifier-syntax
have been added with minor core changes. The library syntax would
have to use implicit phasing and probably punt on versioning. There
would be some minor differences in semantics, but I believe e.g. most
or all of the portable SRFI libraries would work fine. [The cool Racket
libraries that I'd like to use wouldn't work because they generally use
the Racket language rather than R6RS.]

I don't have time to work on this myself.

--
Alex

[Lassi Kortela]

>> Who will add R6RS support to Chibi? (Another rhetorical question.)

> I'm happy to accept patches which improve R6RS operability without
> significant increases to the core size. syntax-case and identifier-syntax
> have been added with minor core changes. The library syntax would
> have to use implicit phasing and probably punt on versioning. There
> would be some minor differences in semantics, but I believe e.g. most
> or all of the portable SRFI libraries would work fine.

Great news!!

IIRC R6 implementers have unanimously settled on implicit phasing as the
right model, but we should confirm that with the R6 wizards.

[Alex Shinn]

On Thu, Mar 17, 2022 at 8:14 PM Alex Shinn <alex...@gmail.com> wrote:
>
> > Who will add R6RS support to Chibi? (Another rhetorical question.)
>
> I'm happy to accept patches which improve R6RS operability without

> significant increases to the core size. [...]

And to be clear, I'm _very_ picky about keeping the core size small.
If someone wants to work on this it's better to ping me first before
putting in a lot of effort.

--
Alex