A Last Ditch Call For Sanity

[elf]

Oke.

So let me get this straight.

We've now replaced one large, inefficient, ponderous committee with
several large, inefficient, ponderous committees.

The basic question of 'what's the point' has not been addressed.

What is the point of doing all of this?

If it is to improve user experience, how is this going to help?

If it is to improve inter-scheme compatibility, how is this going to help?

There's several major problems with the whole approach:

1) No major implementors - with exception of Marc Feeley - are involved
in this process at ALL. Even if you get some kind of agreement - by
people who have not actually implemented a large scale scheme and are
aware of the problems, pitfalls, and issues - who is going to actually
implement it and why?

2) The major voices seem obsessed with solving a problem that isn't a
problem. There's a huge focus on problems of the past whilst utterly
ignoring that they're wholly irrelevant for the future. The problems of
r6 vs r5 vs r7 are not purely technical; they are primarily
social/political, and a process that is an outcropping of the broken
process that created the r6 problem in the first place is not going to
be accepted by those who rejected it.

3) Has anyone asked why there is the diversity of schemes in the first
place and the strengths of there being such diversities? What is
possible to do in, say, minischeme on my phone is not possible to do in
guile. What is possible in guile is not possible in chez. What is
possible in chez is not possible in chicken. (All of these are
bidirectional.) The strength of this approach is that it is possible to
choose the right scheme for the constraints in a given situation, be
they memory, time, architecture, etc. The effort of porting between them
is a hell of a lot less than people seem to think.

4) The major problem is NOT whether old code can be ported, as it
usually can be, with a minimum of effort, as ANYONE WHO HAS ACTUALLY
DONE THIS WOULD ALREADY KNOW. The major problem, as I see it, is that we
have a wholly irrelevant set of problems taking away time and resources
and community effort from things that would actually be important for
the language, eg (most importantly) networking, which is _the_ major
issue in porting between schemes today and the thing that is hardest to
reconcile with _every_ spec of scheme, as the concept of ports in their
current form as the basic IO abstraction is not compatible with
multi-step setup, two-sided control, and OOB data that is inherent in
networking.


Please - stop all of this nonsense and think. How is what you're all
spewing into the void going to actually help? Who is actually going to
implement it and why would they want to do so?

WILL IT ACTUALLY SOLVE ANY OF THE UNDERLYING PROBLEMS?

-elf

[Marc Nieper-Wißkirchen]

Am Do., 24. März 2022 um 10:26 Uhr schrieb elf <e...@ephemeral.net>:

> 1) No major implementors - with exception of Marc Feeley - are involved
> in this process at ALL. Even if you get some kind of agreement - by
> people who have not actually implemented a large scale scheme and are
> aware of the problems, pitfalls, and issues - who is going to actually
> implement it and why?

I understand that it would be better to have more implementers on
board, but we already have more than Marc Feeley. For example, both
Chibi's and Gauche's implementers have been quite active in the
development of the large language so far. Admittedly, the goals and
the scope of Chibi and Gauche may differ a bit from those of what a
prototypical R7RS large implementation may be.

Also, just because most of us have never published a major Scheme
implementation doesn't mean that we wouldn't necessarily be aware of
problems, pitfalls, and issues.

I agree that for R7RS large to become a success, we will need it to be
implemented by some of the most competitive Scheme systems.

> 2) The major voices seem obsessed with solving a problem that isn't a
> problem. There's a huge focus on problems of the past whilst utterly
> ignoring that they're wholly irrelevant for the future. The problems of
> r6 vs r5 vs r7 are not purely technical; they are primarily
> social/political, and a process that is an outcropping of the broken
> process that created the r6 problem in the first place is not going to
> be accepted by those who rejected it.

What is the alternative? When mostly taking the intersection of
existing implementations, you can achieve acceptance, but you won't
get father than R5RS/R7RS. If you want to move forward to make the
language simpler to use for the programmer who doesn't want to care
about idiosyncrasies of the various Scheme implementation, you will
necessarily leave those implementations behind that are unwilling to
follow. This was the outcome of R6RS and this will be the outcome of
the large language. Is this necessarily bad? Those wanting a small
language and those implementations who don't want to have too much
prescribed still have the small language, or even R4RS or R5RS.

> 3) Has anyone asked why there is the diversity of schemes in the first
> place and the strengths of there being such diversities? What is
> possible to do in, say, minischeme on my phone is not possible to do in
> guile. What is possible in guile is not possible in chez. What is
> possible in chez is not possible in chicken. (All of these are
> bidirectional.) The strength of this approach is that it is possible to
> choose the right scheme for the constraints in a given situation, be
> they memory, time, architecture, etc. The effort of porting between them
> is a hell of a lot less than people seem to think.

This is basically questioning standardization, isn't it?

I agree that a lot of porting is simple or trivial. However, as soon
as we talk about procedural macros, delimited continuations, exception
handling, ... porting is not so straightforward anymore.

But porting is probably not even the main point of standardization. It
is first and foremost to create a language that is independent of
vendors and that is well-defined, making code written in it somewhat
timeless.

> 4) The major problem is NOT whether old code can be ported, as it
> usually can be, with a minimum of effort, as ANYONE WHO HAS ACTUALLY
> DONE THIS WOULD ALREADY KNOW. The major problem, as I see it, is that we
> have a wholly irrelevant set of problems taking away time and resources
> and community effort from things that would actually be important for
> the language, eg (most importantly) networking, which is _the_ major
> issue in porting between schemes today and the thing that is hardest to
> reconcile with _every_ spec of scheme, as the concept of ports in their
> current form as the basic IO abstraction is not compatible with
> multi-step setup, two-sided control, and OOB data that is inherent in
> networking.

People work in their free time on things they want to do. Some work on
Scheme implementations, others work on writing Scheme specifications.
Another group may think of new networking interfaces to Scheme. By
saying to those who work on specs do irrelevant work - whether it is
true or not - won't increase the number of people working on a Scheme
implementation or on getting networking "right" in Scheme.

Marc

[Nala Ginrut]

I'd like to comment on some of the questions.

 

On Thu, Mar 24, 2022 at 5:26 PM elf <e...@ephemeral.net> wrote:

Oke.

So let me get this straight.

We've now replaced one large, inefficient, ponderous committee with
several large, inefficient, ponderous committees.

I think it's just trying to make the division of the labor more explicitly, no?

 

1) No major implementors - with exception of Marc Feeley - are involved
in this process at ALL. Even if you get some kind of agreement - by
people who have not actually implemented a large scale scheme and are
aware of the problems, pitfalls, and issues - who is going to actually
implement it and why?

I think there're contributors from major implementations who are getting involved in the discussion, wouldn't it be enough?

2) The major voices seem obsessed with solving a problem that isn't a
problem. There's a huge focus on problems of the past whilst utterly
ignoring that they're wholly irrelevant for the future. The problems of
r6 vs r5 vs r7 are not purely technical; they are primarily
social/political, and a process that is an outcropping of the broken
process that created the r6 problem in the first place is not going to
be accepted by those who rejected it.

My understanding is that R7RS is intended to be incompatible with R6RS, it's a fresh new start, no?

 

3) Has anyone asked why there is the diversity of schemes in the first
place and the strengths of there being such diversities? What is
possible to do in, say, minischeme on my phone is not possible to do in
guile. What is possible in guile is not possible in chez. What is
possible in chez is not possible in chicken. (All of these are
bidirectional.) The strength of this approach is that it is possible to
choose the right scheme for the constraints in a given situation, be
they memory, time, architecture, etc. The effort of porting between them
is a hell of a lot less than people seem to think.

I've been using Guile for making deliverable projects for a decade.

To my experience, Guile had added so many features outside the RnRS just because the RnRS didn't provide them.

And we can't make any meaningful product without these features, we didn't even have library standards before R6RS.

I think the situation is similar to other implementations, people need features for actual work, but RnRS doesn't have them.

R6RS makes some of them, but it's too far from it.

That's why there're so many implementations have unportable features.

R7RS-small is good for embedded systems, and I've used it so.

However, R7RS-large is expected to have rich modern features for industry cases.

For academic purposes, I think R7RS-small is enough.

 

4) The major problem is NOT whether old code can be ported, as it
usually can be, with a minimum of effort, as ANYONE WHO HAS ACTUALLY
DONE THIS WOULD ALREADY KNOW. The major problem, as I see it, is that we
have a wholly irrelevant set of problems taking away time and resources
and community effort from things that would actually be important for
the language, eg (most importantly) networking, which is _the_ major
issue in porting between schemes today and the thing that is hardest to
reconcile with _every_ spec of scheme, as the concept of ports in their
current form as the basic IO abstraction is not compatible with
multi-step setup, two-sided control, and OOB data that is inherent in
networking.

I think the porting means to make a minimum of effort or no effort to make it run on another platform.

Anyway, I'm trying to make it clear if commitee E is mainly focus on this issue.

If yes, we have a dedicated commitee to discuss this issue. 

 

Please - stop all of this nonsense and think. How is what you're all
spewing into the void going to actually help? Who is actually going to
implement it and why would they want to do so?

WILL IT ACTUALLY SOLVE ANY OF THE UNDERLYING PROBLEMS?

I think the better choice would be to stop complaining and see what we can do.

What I'm trying to discuss is going to be implemented in my R7RS compatible implementation.

I can't speak for others, but I do the things that I can, and I'll practice it.

 Best regards.

[Marc Nieper-Wißkirchen]

Am Do., 24. März 2022 um 12:30 Uhr schrieb Nala Ginrut <nalag...@gmail.com>:

[...]

> On Thu, Mar 24, 2022 at 5:26 PM elf <e...@ephemeral.net> wrote:

[...]

>> 2) The major voices seem obsessed with solving a problem that isn't a
>> problem. There's a huge focus on problems of the past whilst utterly
>> ignoring that they're wholly irrelevant for the future. The problems of
>> r6 vs r5 vs r7 are not purely technical; they are primarily
>> social/political, and a process that is an outcropping of the broken
>> process that created the r6 problem in the first place is not going to
>> be accepted by those who rejected it.
>>
>
> My understanding is that R7RS is intended to be incompatible with R6RS, it's a fresh new start, no?

What do you mean by that?

Producing something that is deliberately incompatible with R6RS
doesn't make any sense.

In fact, through the language to be specified by Committee F, I hope
that we will see a platform compatible with both current major
standards - R7RS small and R6RS - and which allows interoperability of
R6RS and R7RS libraries in the same process.

[Nala Ginrut]

On Thu, Mar 24, 2022 at 7:39 PM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> My understanding is that R7RS is intended to be incompatible with R6RS, it's a fresh new start, no?

What do you mean by that?

Producing something that is deliberately incompatible with R6RS
doesn't make any sense.

In fact, through the language to be specified by Committee F, I hope
that we will see a platform compatible with both current major
standards - R7RS small and R6RS - and which allows interoperability of
R6RS and R7RS libraries in the same process.

The exception handling and record type is incompatible with R6RS, isn't it intended?

I'm still confused with the R6 and R7 compatibility policies.

Best regards.

 

[Marc Nieper-Wißkirchen]

Am Do., 24. März 2022 um 12:57 Uhr schrieb Nala Ginrut <nalag...@gmail.com>:
>
>
>
> On Thu, Mar 24, 2022 at 7:39 PM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>>
>> > My understanding is that R7RS is intended to be incompatible with R6RS, it's a fresh new start, no?
>>
>> What do you mean by that?
>>
>> Producing something that is deliberately incompatible with R6RS
>> doesn't make any sense.
>>
>> In fact, through the language to be specified by Committee F, I hope
>> that we will see a platform compatible with both current major
>> standards - R7RS small and R6RS - and which allows interoperability of
>> R6RS and R7RS libraries in the same process.
>>
>
> The exception handling and record type is incompatible with R6RS, isn't it intended?

The exception systems of R6RS and R7RS do not differ. On top of that,
R6RS has a condition system, which R7RS small doesn't have, but it's
not incompatible with R7RS small to add R6RS's condition system. The
large language will take erroneous conditions more seriously than the
small language, so it will probably need some form of a standardized
condition system. It doesn't make sense to create one deliberately
incompatible with the R6RS system.

The R7RS define-record-type syntax is different from the R6RS
define-record-type system but the underlying record systems are not
incompatible so an implementation can easily support both syntaxes or
even merge them into one as shown by Larceny. The R7RS record-type
syntax is somewhat of a dead-end when it comes to adding new features
like non-generative record types or opaque record types. R7RS large
can easily offer both syntaxes with the R7RS syntax for simple record
types when SRFI 9 compatibility is useful and the R6RS syntax for more
general record types and for a more succinct style.

I think it wasn't the intention of the small authors to create
something incompatible with R6RS's define-record-type (but it has to
be said that some misconceptions about the R6RS record-type were
circulated), but that there was just a majority for SRFI 9. For the
small language, SRFI 9's capabilities were all that was needed but it
might not be the best foundation for the large language.

> I'm still confused with the R6 and R7 compatibility policies.

The large language has to be compatible with the R7RS small language.
But mostly thanks to the freedom the small language still leaves and
thanks to the library system, there's no reason why the large language
could not be compatible with R6RS as well. In fact, the charter for
the large language says that "Insofar as practical, the language
should be backwards compatible with an appropriate subset of the R6RS
standard." and I think we can actually achieve mostly full
compatibility here, allowing implementations to support both R6RS and
the large language in the same program/Scheme process. It's an
important feature we should be able to offer to the implementers of
current sophisticated R6RS implementations.

[Dr. Arne Babenhauserheide]

elf <e...@ephemeral.net> writes:
> 1) No major implementors - with exception of Marc Feeley - are
> involved in this process at ALL. Even if you get some kind of
> agreement - by people who have not actually implemented a large scale
> scheme and are aware of the problems, pitfalls, and issues - who is
> going to actually implement it and why?

Andy Wingo from Guile won’t take part himself, but he’ll happily answer
questions if there’s something for which we need input from Guile.

He assumes that Guile will be able to implement whatever part of r7rs
becomes important.

(I asked)

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

[Martin Rodgers]

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

> The R7RS define-record-type syntax is different from the R6RS
> define-record-type system but the underlying record systems are not
> incompatible so an implementation can easily support both syntaxes or
> even merge them into one as shown by Larceny. The R7RS record-type
> syntax is somewhat of a dead-end when it comes to adding new features
> like non-generative record types or opaque record types. R7RS large
> can easily offer both syntaxes with the R7RS syntax for simple record
> types when SRFI 9 compatibility is useful and the R6RS syntax for more
> general record types and for a more succinct style.

R7RS's define-record-type is simply a subset of SRFI 99's
define-record-type. The sample implementation is defined in terms of
the R6RS's define-record-type procedural and inspection layer.

Please note how the sealed and opaque features of R6RS are intentially
not a part of SRFI 99, but may be added via another SRFI. This is a
layered approach to language design. I see no reason why a layered
approach can't be applied in R7RS. It can be extended using SRFIs just
like earlier reports. R7RS Small can also be extended in layers in a
similar way. My understanding is that a broach consensus on this
already exists, via the optional library aspect of R7RS Large.

So I'm mostly in a agreement here, but I'm with William Clinger on the
incompatibility of the R6RS define-record-type syntactic and
procedural layers. I support the SRFI 9 and SRFI 99 layering. I will
likewise support a further layer for sealed and opaque
syntax/semantics.

> I think it wasn't the intention of the small authors to create
> something incompatible with R6RS's define-record-type (but it has to
> be said that some misconceptions about the R6RS record-type were
> circulated), but that there was just a majority for SRFI 9. For the
> small language, SRFI 9's capabilities were all that was needed but it
> might not be the best foundation for the large language.

I strongly urge that any R7RS Large extentions to define-record-type
be compatitible with SRFI 9 and SRFI 99. I have no skin in the details
of how SRFI 99 may be extended by WG2. I'm confident that a pragmatic
solution can be found.

So I'll simply warn against assuming that R7RS Large systems will, if
extending define-record-type beyond the Small definition, necessarily
provide the full syntax and semantics of the final Large definition.
I'd like the Large definition to instead all possible subsets of the
libraries that offer the extentions, including just the SRFI 99
syntactic layer. This will give implementers the maximum freedom while
simultaneously imposing no restrictions.

For example, a possible R7RS system might provide everything in the
Small dialect (a requirement of Large, after all) while only adding
the syntactic layer of SRFI 99. This would be just one choice amoung
the many combinations I'd like R7RS Large to provide to implementers.

I think this way we might reach the greatest consensus on
define-record-type in R7RS Large. I hope its obvious that I'm thinking
here not just of the WG2 consensus, but that of the wider Scheme
community. It shouldn't be necessarily to point this out, but I'd like
it on record. (No pun intended.)

Apologies for yet another long-winded post just to make (I hope) a simple point.

[Marc Nieper-Wißkirchen]

Am Do., 24. März 2022 um 17:48 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:
>
> On 24/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
> > The R7RS define-record-type syntax is different from the R6RS
> > define-record-type system but the underlying record systems are not
> > incompatible so an implementation can easily support both syntaxes or
> > even merge them into one as shown by Larceny. The R7RS record-type
> > syntax is somewhat of a dead-end when it comes to adding new features
> > like non-generative record types or opaque record types. R7RS large
> > can easily offer both syntaxes with the R7RS syntax for simple record
> > types when SRFI 9 compatibility is useful and the R6RS syntax for more
> > general record types and for a more succinct style.
>
> R7RS's define-record-type is simply a subset of SRFI 99's
> define-record-type. The sample implementation is defined in terms of
> the R6RS's define-record-type procedural and inspection layer.
>
> Please note how the sealed and opaque features of R6RS are intentially
> not a part of SRFI 99, but may be added via another SRFI. This is a
> layered approach to language design. I see no reason why a layered
> approach can't be applied in R7RS. It can be extended using SRFIs just
> like earlier reports. R7RS Small can also be extended in layers in a
> similar way. My understanding is that a broach consensus on this
> already exists, via the optional library aspect of R7RS Large.

The SRFI 99 design is not fully compatible with R7RS small (for an
explanation see SRFI 150's rational). Without gensyms, SRFI 99's
design is even unnecessarily limited when we don't consider
compatibility to the small language.

> So I'm mostly in a agreement here, but I'm with William Clinger on the
> incompatibility of the R6RS define-record-type syntactic and
> procedural layers. I support the SRFI 9 and SRFI 99 layering. I will
> likewise support a further layer for sealed and opaque
> syntax/semantics.

Despite what William Clinger said, the R6RS syntactic and procedural
layers are not incompatible.

> > I think it wasn't the intention of the small authors to create
> > something incompatible with R6RS's define-record-type (but it has to
> > be said that some misconceptions about the R6RS record-type were
> > circulated), but that there was just a majority for SRFI 9. For the
> > small language, SRFI 9's capabilities were all that was needed but it
> > might not be the best foundation for the large language.
>
> I strongly urge that any R7RS Large extentions to define-record-type
> be compatitible with SRFI 9 and SRFI 99. I have no skin in the details
> of how SRFI 99 may be extended by WG2. I'm confident that a pragmatic
> solution can be found.

Compatible extensions to SRFI 9 are possible, even those supporting
the full R6RS protocol. SRFI 99 is, as said above, not compatible with
SRFI 9 as specified by R7RS small.

> So I'll simply warn against assuming that R7RS Large systems will, if
> extending define-record-type beyond the Small definition, necessarily
> provide the full syntax and semantics of the final Large definition.
> I'd like the Large definition to instead all possible subsets of the
> libraries that offer the extentions, including just the SRFI 99
> syntactic layer. This will give implementers the maximum freedom while
> simultaneously imposing no restrictions.

As long as the syntactic abstraction facilities provided by the large
language are powerful enough, the surface syntax is not really
important as they will then be implementable by a portable library,
which can then be shipped by every R7RS large implementation.

If you want maximal freedom, I think you want to implement the small
language (+ additions).

> For example, a possible R7RS system might provide everything in the
> Small dialect (a requirement of Large, after all) while only adding
> the syntactic layer of SRFI 99. This would be just one choice amoung
> the many combinations I'd like R7RS Large to provide to implementers.

To make parts of the large language optional makes sense, but it
doesn't make sense IMO to allow just arbitrary combinations. If we did
that, the large language would already be obsolete because we already
have the small language plus the collection all SRFIs that are
basically optional.

> I think this way we might reach the greatest consensus on
> define-record-type in R7RS Large. I hope its obvious that I'm thinking
> here not just of the WG2 consensus, but that of the wider Scheme
> community. It shouldn't be necessarily to point this out, but I'd like
> it on record. (No pun intended.)

All that a Scheme system has to provide will be some way of defining
disjoint types. The rest can then be provided by portable syntax and
procedures so implementers won't have a good reason not to ship the
record system of R7RS large (whatever it will be). For example,
Unsyntax ships with R7RS record types but also with R6RS record types
and runs on any small system.

Threads would be a completely different matter; these need
considerable support by an implementation's core, so here it makes
sense to make them optional - or to make fair scheduling optional at
least.

Marc

[John Cowan]

On Thu, Mar 24, 2022 at 7:39 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

 

In fact, through the language to be specified by Committee F, I hope
that we will see a platform compatible with both current major
standards - R7RS small and R6RS - and which allows interoperability of
R6RS and R7RS libraries in the same process.

I see several possible interpretations of that:

1) R7RS-large includes the R6RS libraries, such that a conforming implementation must provide them.

2) The R6RS libraries can be portably implemented on top of the foundation language.

3) The R6RS libraries can be implemented side-by-side with the foundation language.

Which do you have in mind?

[Lassi Kortela]

> 1) R7RS-large includes the R6RS libraries, such that a conforming
> implementation must provide them.
>

> [...]

Missing the IMHO best alternative:

4) R7RS-large includes the R6RS libraries as OPTIONAL modules, such that
a conforming implementation MAY provide them.

This lets "the market" sort out how much compatibility to provide, and
where.

The immediately painful thing is that (library ...) and (define-library
...) are not available in the same Scheme implementations, which means
we can't `cond-expand` our way out of problems.

[John Cowan]

Since MAY means the same thing as MAY NOT, that imposes nothing on the standard.

--
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/ef686882-a649-dc63-20ce-11aafa5c5450%40lassi.io.

[Marc Nieper-Wißkirchen]

The most crucial point is 3). If 3) were not given, interoperability
would not be given and we would see fewer implementations of R7RS
large because the existing R6RS implementations that wish to remain
R6RS compatible would be out of the game.

Given that the foundations will most likely be a superset of R6RS (not
in terms of individual APIs but in terms of capabilities), 2) will
probably follow from 3).

But with 2), the answer to 1) is more of a political than a technical
question as the large project could offer a portable R6RS standard
library implementation if there are volunteers to do the programming.

For the foundation language, it is important that it either specifies
the semantics of a Scheme process using R6RS and R7RS parts or that it
includes everything from both worlds anyway. (The latter does not
preclude talking about optional parts).

Having available both (scheme base) and (rnrs base (7)), say, is much
better than it may sound to purists (like me): In program parts where
you want the strictness R6RS offers, you would import (rnrs base (7));
in program parts where you want to use the freedom/anarchy :) of R7RS
small, you would import (scheme base). I've already posted a mechanism
on the WG2 mailing list (which can be standardized by the foundations)
how to allow a program to import both of, say, (rnrs base (7)) and
(scheme base) simultaneously into the same namespace so that, say,
(scheme base)'s map overrides (rnrs base)'s map. The foundations would
have to specify the interaction in detail, of course.

[Martin Rodgers]

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

> If you want maximal freedom, I think you want to implement the small
> language (+ additions).

Yes, that would, I think, give WG2 and implementers (and users, both
today and in the future) maximal freedom.

Your points about hygiene are noted. Thanks.

[Marc Nieper-Wißkirchen]

Am Do., 24. März 2022 um 21:54 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:
>
> On 24/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
> > If you want maximal freedom, I think you want to implement the small
> > language (+ additions).
>
> Yes, that would, I think, give WG2 and implementers (and users, both
> today and in the future) maximal freedom.

I understand your point about the implementer's freedom. But what do
you mean by user's freedom in this respect? Do you think that if a
standard prescribes substantially more than what is currently in the
small language, implementations will assimilate, removing the freedom
to choose different approaches to solving problems from the users?

[Martin Rodgers]

On 24/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
> Am Do., 24. März 2022 um 21:54 Uhr schrieb Martin Rodgers
> <mcro...@gmail.com>:

>> Yes, that would, I think, give WG2 and implementers (and users, both
>> today and in the future) maximal freedom.
>
> I understand your point about the implementer's freedom. But what do
> you mean by user's freedom in this respect? Do you think that if a
> standard prescribes substantially more than what is currently in the
> small language, implementations will assimilate, removing the freedom
> to choose different approaches to solving problems from the users?

I'm refering to the freedom to use #1 use R7RS Small & SRFIs and #2
continue using the same code, unchanged, when R7RS is complete and
stable, then #3 optionally "port" that code to the final R7RS
language.

Perhaps this is a matter of coding style. There are Schemes supporting
R5RS, R6RS and R7RS. They also support SRFIs. More SRFIs may be added
with a sample implementation. Some Schemes support only one Scheme
report and yet can still support many SRFIs.

Is there a risk that "implementations will assimilate, removing the freedom
to choose" anything? I don't think so. I'm simply providing a
definition of "maximal freedom" that serves WG2, implementers and
users in a particular way. It's a way that works well for me, but
YMMV.

Of course I'm ignoring details that complicate a few things. That's
why I say Your Mileage May Vary. I have a lot more to think about now,
which is a good thing. Thanks for your insights.

[Marc Nieper-Wißkirchen]

Am Fr., 25. März 2022 um 01:30 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:
>
> On 24/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
> > Am Do., 24. März 2022 um 21:54 Uhr schrieb Martin Rodgers
> > <mcro...@gmail.com>:
>
> >> Yes, that would, I think, give WG2 and implementers (and users, both
> >> today and in the future) maximal freedom.
> >
> > I understand your point about the implementer's freedom. But what do
> > you mean by user's freedom in this respect? Do you think that if a
> > standard prescribes substantially more than what is currently in the
> > small language, implementations will assimilate, removing the freedom
> > to choose different approaches to solving problems from the users?
>
> I'm refering to the freedom to use #1 use R7RS Small & SRFIs and #2
> continue using the same code, unchanged, when R7RS is complete and
> stable, then #3 optionally "port" that code to the final R7RS
> language.

I don't see why you shouldn't be able to continue using the same code
as before. Earlier dialects don't go away just because there's a new
kid in town. Programs written in R4RS, R5RS, or R6RS haven't become
obsolete because the newest standard is called R7RS. But even more
importantly, the large language will be virtually compatible with the
small language so every implementation of the large language
implementing the needed SRFIs will be able to run your code written
for the small language.

Whether you "port" your code to make full use of the large language is
a different matter. I would say that the large language is large
enough to support all kinds of programming styles: Programs using only
a minimal subset of Scheme (as defined in the small language or as
defined in R4RS or R5RS), programs written for R6RS and its style,
programs written with the full large language in mind and, finally,
programs ported from some other language (like Java, Python, Clojure,
C++) that have their own idiosyncrasies.

> Perhaps this is a matter of coding style. There are Schemes supporting
> R5RS, R6RS and R7RS. They also support SRFIs. More SRFIs may be added
> with a sample implementation. Some Schemes support only one Scheme
> report and yet can still support many SRFIs.

I'm afraid that I don't see your point here.

> Is there a risk that "implementations will assimilate, removing the freedom
> to choose" anything? I don't think so. I'm simply providing a
> definition of "maximal freedom" that serves WG2, implementers and
> users in a particular way. It's a way that works well for me, but
> YMMV.
>
> Of course I'm ignoring details that complicate a few things. That's
> why I say Your Mileage May Vary. I have a lot more to think about now,
> which is a good thing. Thanks for your insights.

It's the old conflict between maximal implementer's freedom and
standardization. As it seems to me we are actually in a position where
we can get the best of all worlds: We have the small language and we
have more than two hundred of SRFIs that won't go away but are still
growing. On the other hand, we will get a large language that will
impose a lot of requirements on implementations.

While I think it is important to have a detailed language
specification with definite semantics for those implementations
willing to support it and for those users wanting a clear, maximal
portable programming model with no surprises, we will also see many
implementations that do not implement the detailed specification
fully. Nevertheless, for a lot of users and for a lot of practical
purposes, an "almost implementation" can be just enough and will be a
valuable addition to the Scheme landscape. To give an example of what
I mean, we have implementations like Chez on the one hand side, that
strive after implementing R6RS correctly. On the other hand, we have
implementations like Guile that do not implement R6RS in all details
but that are nevertheless a usable R6RS platform. A similar thing we
will see with the large language. While Chibi may not implement all
syntactic abstraction facilities of the large language faithfully, it
will probably be able to serve as a good platform for programs for the
large language in many practical situations.

[Martin Rodgers]

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

> I don't see why you shouldn't be able to continue using the same code
> as before. Earlier dialects don't go away just because there's a new
> kid in town. Programs written in R4RS, R5RS, or R6RS haven't become
> obsolete because the newest standard is called R7RS. But even more
> importantly, the large language will be virtually compatible with the
> small language so every implementation of the large language
> implementing the needed SRFIs will be able to run your code written
> for the small language.

That's my point. I was simply answering your earlier question.

I think we're in strong agreement. ;)

>> Perhaps this is a matter of coding style. There are Schemes supporting
>> R5RS, R6RS and R7RS. They also support SRFIs. More SRFIs may be added
>> with a sample implementation. Some Schemes support only one Scheme
>> report and yet can still support many SRFIs.
>
> I'm afraid that I don't see your point here.

It's the same point I've made here several times now, but in reply to
your earlier question.

> While I think it is important to have a detailed language
> specification with definite semantics for those implementations
> willing to support it and for those users wanting a clear, maximal
> portable programming model with no surprises, we will also see many
> implementations that do not implement the detailed specification
> fully. Nevertheless, for a lot of users and for a lot of practical
> purposes, an "almost implementation" can be just enough and will be a
> valuable addition to the Scheme landscape. To give an example of what
> I mean, we have implementations like Chez on the one hand side, that
> strive after implementing R6RS correctly. On the other hand, we have
> implementations like Guile that do not implement R6RS in all details
> but that are nevertheless a usable R6RS platform. A similar thing we
> will see with the large language. While Chibi may not implement all
> syntactic abstraction facilities of the large language faithfully, it
> will probably be able to serve as a good platform for programs for the
> large language in many practical situations.

Indeed, I think we're in agreement here also.

As I've said here before, I have a Scheme compiler of my own, written
in a language that Chibi and Larceny will accept. My compiler itself
will accept a language that supports itself. Beyond that, I'm now very
reluctant to claim any compatibility with R7RS. It might be possible
to claim support for the Small dialect, but probably not the Large
dialect.

Of course, this is still a work in progress - one of the risks of
implementing a language while the definition is growing and changing -
but sometimes that's hard to avoid. I've obvserved similar issues in
other languages. In one case, in 1995, I recall a programmer
commenting that it was "hard to find a book in sync with a compiler in
sync with the language" due to the rapidity of change. (However, see
my comment below regarding 'cleanup'.)

Due to the nature of Scheme, much of the language is defined by the
runtime library. There's also the core/derived distinction.

This may be further complicated by the bluring of run time and compile
time. Most of my concerns here relate to this distinction. I only
mention my own compiler because there are so few well know, widely
available, and easy to use Scheme compilers that make this hard
distinction. (Stalin immediately springs to mind.) I can at least
cautiously claim to support an intersection of syntax of semantics.

Clearly there should be a 'cleanup' stage for my own code once
committee C has completed theirs. ;) Until then, I should closely
follow the progress of WG2 to ensure I understand and appreciate the
issues. I'd like to thank everyone here for their insights so far.

So my concerns in this context regarding define-record-type may be
satisfied by only using the SRFI 9. No procedural layer. No inspection
layer. I get around this by using a layer on top
(define-datatype/cases). Perhaps a procedural layer might make this
easier. I know from experience how much syntax-case can help. I also
know its possible to manage without these features (using Chibi and
Larceny), but perhaps someday I'll find a compliant R7RS system on
which my code breaks.

I don't know how common this experience may be, but perhaps you can
comment. I know there's Scheme code that works with some Scheme
systems but not others. The SRFI 53 sample implementation is one
example. (However, SRFI 53 is now withdrawn.) I've encountered similar
issues myself. Other times, I've found ways around those issues (like
the renaming technique used in, for example, the SRFI 227 sample
implementation). SRFI 148 is also of interest to me.

Thanks again for your insights. I hope this reply answers your
question without raising (too many) more questions.