Suggestions for improvement of the R7RS Large/WG2 process

[Daphne Preston-Kendal]

As I have been involved in the development of R7RS Large over the last
two years or so, I have become concerned with the general
disorganization of the current WG2 process. As promised recently, here
is a summary (nearly 2,500 words, sigh, but I tried to keep it short)
of what I think we could be doing better.

I have three main criticisms of the current process and, at the end,
suggestions for how these issues might be resolved.


1. The Small Language as the Basis of the Large Language

The R7RS small process created a language which well fulfils the goals
WG1 set out to achieve: it is a modest extension of the R5RS laying the
groundwork for a much larger language. The main provision in the small
language for the many future extensions to be provided by the Large
language was the library system.

Unfortunately, the R7RS small language unmodified is *un*suitable for
the task of building R7RS Large in a number of ways. It is no secret
that R7RS small is ‘compromised’, in the literal sense: multiple
conflicting concerns existed, and compromises had to be met to satisfy
each of them imperfectly. The two main conflicting interests can be
summarized briefly as strictness vs flexibility: strictness, to
satisfy the desire of programmers for a consistent environment across
implementations; flexibility, to allow implementors to target unusual
or resource-limited platforms, and to adapt their existing R5RS
implementations which may already have had certain assumptions baked
into them. These compromises were all very reasonable, given the
design requirements of R7RS small:

> The language is intended for use in education, programming-language
> research, embedded systems, and embedded scripting languages. It will
> also be a platform on which other languages can be built. For these
> uses, a language that is "lightweight" at the semantic and/or
> implementation level is appropriate.
>
> The language should be easy for a human to learn and understand. It
> should be easy to make an unsophisticated implementation for research,
> development, and study, and it should be possible to make a
> sophisticated implementation that is suitable for serious computation.
> A sophisticated implementation should be an appropriate kernel for a
> larger Scheme system.
<http://www.scheme-reports.org/2009/working-group-1-charter.html>

The design requirements of R7RS Large are less well-specified, but
explicitly distinct:

> a language that embodies the essential character of Scheme, that is
> large enough to address the practical needs of mainstream software
> development
[…]
> The language is not necessarily intended for educational, research, or
> embedded use, though such uses are not prohibited.
<https://small.r7rs.org/wiki/WG2Charter/>

So, for example, the programmer may wish to be able to use any Unicode
character in any context; but this is a heavy burden for embedded
environments and unsophisticated implementations, thus the compromise:
in the small language, only ASCII was required, but if more characters
were supported, they had to be supported in a way consistent with the
Unicode standard. Also, null characters in strings were ‘an error’.

This is the nub of the problem with R7RS small: it quite simply leaves
too much up to the whims of the implementor to be a practical language
for ‘mainstream software development’. One of the first requirements of
R7RS Large should therefore have been to tighten up R7RS and take some
of that flexibility away from implementors in exchange for real
guarantees for programmers.

At the very least, ‘it is an error’ conditions in R7RS small which can
make it impossible to write applications processing untrusted input
with a guarantee of security ought to be tightened up to make a
practical Large language. There are nearly 70 explicitly-named errors
causing undefined behaviour in R7RS small. Perhaps a dozen of these
can easily be seen to have security implications; there may be others
lurking in error conditions which are *not* explicitly named.
<https://github.com/johnwcowan/r7rs-work/blob/master/ItIsAnError.md>

There is currently no clear plan for resolving these crucial issues in
the development of a practical standard Scheme language for real
software development. It is also not clear that the current procedure by
which R7RS Large is being developed is even capable of resolving such a
large number of related, often quite nuanced questions: while rounds of
voting on ballots listing SRFIs has proven productive (though not
necessarily good, for which see the next section) as a means of choosing
which new libraries to adopt for the Scheme standard, it has not really
proven its suitability for deciding any other aspect of the R7RS Large
language design.


2. The SRFI-Based Voting Process

When WG2 awoke from its dormancy after the completion of R7RS small,
the chair immediately revised its charter in two significant ways:
firstly, the former restricted membership of WG2 was dissolved and
replaced by open participation of the whole Scheme community;
secondly, the R7RS process was re-oriented around the existing SRFI
process, so that all proposals either had to come from SRFIs or,
unmodified, from the R6RS.

The SRFI-based process does not take account of the need to create a
self-consistent language (‘Self consistency is an important objective’
according to the WG2 charter), which has already led to a debate over
the name of cut/cute and <>/<...> from SRFI 26, after SRFI 26 was
already accepted not only in principle, but (theoretically) in exact
specification form. One reason for this is that it fails to allow
broader principles to be decided before fine details are worked out:
SRFIs must be complete specification documents with working
implementations. By contrast, the small language process decided broad
principles according to which the language would be developed, before
more specific proposals were made.

Another major reason the self-consistency of R7RS Large cannot be
guaranteed by the current process is because, as Marc Nieper-Wißkirchen
has said, while the choices of any one voter may add up to a consistent
language design, the weighted average of a large group’s choices will
probably not. The small process was able to resolve this issue by (a)
having a smaller, fixed-size committee and (b) use of a Condorcet voting
system so all proposals had the maximum possible approval of the group.
WG2 has thus far used majoritarian voting (in some cases, with de facto
run-offs, such as on the question of the string library).

Resolving such consistency issues is also made more difficult by an
artifically-imposed compatibility restriction: John Cowan has
explicitly stated that he does not intend to remove anything from an
‘Edition’ of R7RS Large which was voted into a previous ‘Edition’.
<https://srfi-email.schemers.org/srfi-discuss/msg/18004344/>

This requirement is unnecessary: there is no charter obligation for
non-final editions of R7RS Large to remain stable; there is no
precedent for such a policy, as pre-final editions of both R7RS small
and R6RS made incompatible changes to previous pre-final editions; and
(perhaps more importantly) there is still no single spec for any such
‘Edition’ of the Large language. (See below.) This position is
especially strange considering John’s own experiences with the
comparator library: he would surely have regretted SRFI 114’s adoption
if the problems with it had not become apparent before the Red Edition
was voted on.

A real example of such a consistency problem has been noted with the
order of arguments to the ‘kons’ procedure given to fold procedures.
The only way to fix this with no incompatibility at all to previous
‘Editions’ is to introduce entirely new fold functions, duplicating
the functionality of the existing ones. This is clearly not ideal from
a self-consistency perspective, even if compatiblity with older (i.e.
pre-R7RS) code may be another argument in favour of that approach.
<https://wiki.dpk.io/r7rs-ultraviolet-issues.html>

But there are other ways to resolve such compatibility concerns,
further emphasizing the pointlessness of backwards-incompatible
changes to pre-final R7RS Large editions: there is no reason in
principle why (scheme list) need be identical with (srfi 1), and no
reason why an implementation support both indefinitely. In other
words, adopting SRFIs as the *basis* of R7RS Large is a good idea (and
in particular a welcome change from R6RS, which too often ignored
existing SRFIs entirely for no apparent good reason), there should be
a process to adopt changes to them for the versions to be adopted in
R7RS to ensure R7RS’s self-consistency even as SRFIs are mutually
inconsistent with one another. (I note as precedent R7RS small’s
changes to SRFI 39 and SRFI 45 in its version of them.)


3. Difficulty of Sharing and Keeping Track of Information

There is little evidence that the vast majority of voters have engaged
sufficiently with the publically-made arguments for and against the
various proposals on the ballot. There were 36 voters on the
Yellow/Kronos Edition ballot, of whom perhaps half a dozen have been
active in the forums for discussing the development of Scheme that I
personally know of. They may have been active in debate in forums I
don’t know about, though, because one major problem of the current
process is that it’s difficult to find out where arguments have been
made at all. Some discussion of proposals happens in srfi-discuss; some
in the individual SRFI mailing lists; some in the scheme-reports-wg2
mailing list; and some points have been raised in the #scheme IRC
channel. The scheme-reports-wg2 mailing list is supposed to be the
central discussion forum, but not all points pro et contra make it
there, and it seems not all voters read it either, as the chair promotes
the ballots in other locations. Some of the write-in votes on the
Yellow/Kronos ballot show that the voters had not read the arguments on
scheme-reports-wg2, or may not even have been aware of the purpose of
the R7RS Large process.

Inequality of information is a sad reality of democracy, but for such a
small groups of voters to have such widely differing amounts of
information when casting their votes is a situation that can hardly even
be called democracy. It decreases the quality of decisions and makes
situations like poor and inconsistent libraries being adopted more
likely.

The situation also makes it hard to understand and compile a rationale
for the inclusion of features or libraries, a very valued feature of
Scheme specifications so far — even of R6RS which was, like R7RS,
designed by voting rather than unanimous consensus.


∞. Conclusions

Therefore, I call for the following changes to the current R7RS process:

1. Open a new, single, centralized place for discussion of R7RS
development — both of new features and problems with the existing
language. This should be set up inside proper project-management
software. Even GitHub or GitLab Issues would probably do. Its use
should be mandatory for people raising issues and making proposals for
things to be added to the Large language: no proposal is eligible to
be voted on or included which has not been made in the project
management system.[*] R7RS Large is done when all tickets in the
project management system have been closed (possibly as ‘won’t fix’),
and not done before all tickets are closed. When ballots are voted on,
each item should be linked to the relevant issue with its discussion
thread so voters can see all the arguments for and against the
proposals. (Voting could even take place over the project management
system instead of over Google Forms as at present, also potentially
removing the arguably-artificial requirement to wait for a docket to
be finished before deciding on an issue.)

2. Establish eligibility criteria for proposals for R7RS Large. To
some extent, the requirement for the majority of proposals to be made
in the form of SRFIs does this; but general principles such as how
platform-specific operating system integration libraries should be,
and to what extent R6RS vs SRFI proposals should be preferred, remain
undefined. There is also no clear process for *proposing* smaller
corrections to adopted libraries which are not worth making into
independent SRFIs, and what backwards-compatibility requirements apply
to such corrections, hampering the process of cleaning up the small
language *and* the inconsistencies which have been found in the Large
language so far — this should be made clear. (I personally have a list
of over fifty issues, mainly related to consistency, which I would
like to see addressed. I will enter them into the issue tracker if it
is opened.)

3. Work on the final specification document for R7RS Large should
begin already, in order to catch consistency issues as soon as
possible.[†] The editor should enter consistency issues etc. into the
issue tracker mentioned in proposal 1 as they arise.


And finally,
4. Consideration (!) should be given to re-establishing a WG2 core
committee of a small number of particularly active and knowledgeable
members with the power to adopt proposals by informal unanimous
consensus without waiting for a vote of the whole WG2 electorate. This
would provide a realistic forum in which, for example, the large numbers
of issues related to backward-compatible cleanup of the WG1 language to
make it more suitable for WG2’s purposes could be resolved efficiently.
It would also allow self-consistency issues to be resolved without
resort to a ballot. The core committee should include people working on
implementations of Scheme as well as people with a serious interest in
writing software in Scheme (but I repeat myself /s).


As one final note, I should say that I have continued confidence in
John Cowan personally as chair. Of course I don’t agree with him on
every point in the design of R7RS Large, but his rôle as chair is
usually not to decide but to facilitate debate and decision, and he
has repeatedly shown himself most capable in this rôle. In fact, I
feel the main problem with his chairmanship so far has been that he
has been hampered in his ability to direct proceedings efficiently by
the lack of clear discussion of R7RS Large issues which I raised in
point 3 in this letter. Neither John nor I nor, I think, anyone
involved in the WG2 process at the moment is able to keep track of all
the pros and cons of various proposals.

As one final final note, I’d like to thank Marc Nieper-Wißkirchen for
reading a draft of this critique and suggesting improvements. In
particular, even this absurdly long email is much shorter thanks to
his suggestions about what specious and irrelevant points to remove.

--
dpk (Daphne Preston-Kendal) ·· 12107 Berlin, Germany ·· http://dpk.io/
we do these things not because they are easy, +49 159 03847809
but because we thought they were going to be easy
— ‘The Programmers’ Credo’, Maciej Cegłowski


Footnotes:

[*] That is, proposing e.g. that a SRFI be adopted, not proposing a
library which should itself be a SRFI. The existing forums for pre-SRFI
proposals and their discussions are probably adequate.

[†] Recent complaints in the #scheme IRC channel about the difficulty of
producing a hypertext version of the R7RS small report suggest that the
master source of this document should *not* be in TeX. Of course, the
PDFs of the Scheme reports look as slick as they do because of TeX;
but a printed version could be produced by converting another markup
language into TeX source.

[Taylan Kammer]

On 21.02.2022 20:39, Daphne Preston-Kendal wrote:
> As I have been involved in the development of R7RS Large over the last
> two years or so, I have become concerned with the general
> disorganization of the current WG2 process. As promised recently, here
> is a summary (nearly 2,500 words, sigh, but I tried to keep it short)
> of what I think we could be doing better.
>

> [...snip...]
>

Thanks for writing this up! I don't think it's too long given the depth
of the topic, and I don't see any point which I see myself disagreeing
with. Not in any major way, anyway.

--
Taylan

[Vincent Manis]

Reposting because of permission problem caused by a weird Google Mail restriction. -- v

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

Subject:	Re: [scheme-reports-wg2] Suggestions for improvement of the R7RS Large/WG2 process
Date:	Mon, 21 Feb 2022 21:00:44 -0800
From:	Vincent Manis <vma...@telus.net>
To:	scheme-re...@googlegroups.com, Daphne Preston-Kendal <d...@nonceword.org>

I want to express strong agreement with Daphne's post. This in no way reflects on the hard work that the main contributors have done to get us this far. However, I have no real understanding of what R7RS-Large will be, when all the SRFIs have been completed. I am nervous that we will vote on the various SRFIs from all the dockets, and then we'll have a collection of SRFIs with no conceptual unity.

For example, I have serious reservations about including JSON support in the language, not because I disapprove of the SRFI, but because JSON is currently a flavor du jour, and might well become less important in the future (and in any case, I don't understand the rationale for supporting JSON but not YAML or TOML, at least on input).  JSON support is important, at a practical level; but I'm not convinced it needs to be an integral part of the language.  A number of the proposals in the

So what I guess I'm saying is that there are facilities that are important, but are not key to the language. If I had my druthers, these would not be part of R7RS-Large, but would be included in a set of portable libraries that would be a worthy successor to Aubrey Jaffer's slib libraries. Exactly what the boundaries of R7RS-Large should be I leave to wiser heads than mine, but I would like to see some kind of boundaries established.

When the Red docket was voted on, I tried to produce a consolidated specification document. I distributed it here, and got zero feedback (apart from a valuable correction to my mistaken ideas about SRFI copyrights). I didn't think it was very good, in particular, there was no coherent outline, and little notational consistency. However, I hoped it would stimulate discussion about what a final R7RS-Large might look like. I haven't seen that discussion.

I would strongly recommend that we pause voting on dockets, and proposing SRFIs, to plan out the shell of a final Report into which we could fit the currently-approved proposals, as well as those we expect to consider.

Nothing in this email should be interpreted as a criticism of the hard work that have got us this far. I am just arguing for a change in emphasis of our work program.

-- vincent

[Vincent Manis]

Reposting again because I inadvertently deleted something in my first try. -- v

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

Subject:	Re: [scheme-reports-wg2] Suggestions for improvement of the R7RS Large/WG2 process
Date:	Mon, 21 Feb 2022 21:00:44 -0800
From:	Vincent Manis <vma...@telus.net>
To:	scheme-re...@googlegroups.com, Daphne Preston-Kendal <d...@nonceword.org>

I want to express strong agreement with Daphne's post. This in no way reflects on the hard work that the main contributors have done to get us this far. However, I have no real understanding of what R7RS-Large will be, when all the SRFIs have been completed. I am nervous that we will vote on the various SRFIs from all the dockets, and then we'll have a collection of SRFIs with no conceptual unity.

For example, I have serious reservations about including JSON support in the language, not because I disapprove of the SRFI, but because JSON is currently a flavor du jour, and might well become less important in the future (and in any case, I don't understand the rationale for supporting JSON but not YAML or TOML, at least on input).  JSON support is important, at a practical level; but I'm not convinced it needs to be an integral part of the language.  A number of the proposals in the various dockets seem to be similarly useful but not central to the language. We do need to think about how BIG the final report will be.

[Duy Nguyen]

On Tue, Feb 22, 2022 at 2:39 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:
> Therefore, I call for the following changes to the current R7RS process:
>
> 1. Open a new, single, centralized place for discussion of R7RS
> development — both of new features and problems with the existing
> language. This should be set up inside proper project-management
> software. Even GitHub or GitLab Issues would probably do. Its use
> should be mandatory for people raising issues and making proposals for
> things to be added to the Large language: no proposal is eligible to
> be voted on or included which has not been made in the project
> management system.[*] R7RS Large is done when all tickets in the
> project management system have been closed (possibly as ‘won’t fix’),
> and not done before all tickets are closed. When ballots are voted on,
> each item should be linked to the relevant issue with its discussion
> thread so voters can see all the arguments for and against the
> proposals. (Voting could even take place over the project management
> system instead of over Google Forms as at present, also potentially
> removing the arguably-artificial requirement to wait for a docket to
> be finished before deciding on an issue.)

Thanks for the write up. I just wanted some clarification here.
Assuming that call item 2 still uses SRFI process for some proposals,
how does it work with this issue tracking system? I suppose an SRFI is
still made separately like before and only enters the issue tracking
system once it's in the final state (the the adoption process starts)?

How does it help with the difficulty of tracking information if we
still go with SRFI process this way? Because some discussions are
still in srfi-<n> mailing lists. And while you can search and read
them all when the srfi is official registered as proposal in this
issue tracking system, it's probably too much. Or will the SRFI
process be changed (for large proposals only) so that all discussions
are in this tracking system? Or drop SRFI entirely?
--
Duy

[Marc Nieper-Wißkirchen]

That's a good point. I'd suggest dropping the current strategy that
R7RS-large libraries map one-to-one to SRFIs. Instead, I propose that
when there is an agreement by WG2 that a particular SRFI is worth
integrating into R7RS-large, WG2 imports the SRFI into R7RS-large, but
all subsequent discussions and changes as far as R7RS-large is
concerned are then discussed within the central R7RS-large discussion
and decision making place. As Daphne wrote, there is no reason why
(srfi 1) and (scheme list) have to be the same. Of course, when the
library within R7RS-large has stabilized enough, the original SRFI
author(s) can amend their SRFI according to the changes R7RS-large did
if they want to.

I immediately see the following three reasons why this approach is a
good one, at least a better one than the current approach.

(1) It allows for a centralized discussion and decision-making place
for R7RS-large.
(2) The final contents of libraries are not dictated by whatever SRFI
author (and WG2 has just the choice between sink or swim), but WG2 can
use whatever process is established to define the final contents of
the library.
(3) Libraries can be polished in view of consistency with the rest of
R7RS-large and this polishing would not be compromised by deference to
the SRFI requirements.

[Daphne Preston-Kendal]

Marc’s description is exactly what I had meant.

> --
> 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/CAEYrNrTFzVc3qdAYMbHiGSWkMiS6p5uPkHTc3i5x%3DBWF7O%2BjWA%40mail.gmail.com.

[Martin Rodgers]

On 21/02/2022, Daphne Preston-Kendal <d...@nonceword.org> wrote:

> The SRFI-based process does not take account of the need to create a
> self-consistent language (‘Self consistency is an important objective’
> according to the WG2 charter),

I strongly agree with this point, while adopting a pragmatic attitude.

Both users and implementers may appreciate and use a language with
inconstances. I learned this from studying Common Lisp and, in
particular, reading the "historical notes" in Guy Steele's reference
book. Kent Pitman's comments in comp.lang.lisp on the process of
creating the language was also informative. While the resulting
language has many issues, with Kent Pitman freely admited (I recall
his "mea culpa" comment regarding just one of the issues), they none
the less achieved their goal of creating a "common language for a
common community."

Similarly, Perl has been compared to a camel, with the point that a
camel is a useful animal in a desert. While we may prefer a horse,
aquiring such an animal may require more time and effort.

So I think the questions here are:

#1 Will we get a horse or a camel?
#2 How much more time and effort will it take to get a horse?
#3 Can we as a community afford that?

Speaking as a user, I very much want a horse. As an implementer, I
want a language with as much code using it, and the surface language
details are mostly just a layer of abstraction over the language core.
So long as those abstractions are written in Small subset, my code
won't care.

However, my primary interest is in studying the performance issues,
and for that I want as much code as possible to feed into my compiler.
Whatever WG2 produces will help with that, providing the language has
a large enough community and large enough codebase for me to compile.
So my focus is rather narrow. I think my contribution here might be
the horse/camel distinction. I hope that helps the discussion.

Thanks to everyone so far. I think this is an important issue, and I
thank Daphne in particular for raising it.

[John Cowan]

On Mon, Feb 21, 2022 at 2:39 PM Daphne Preston-Kendal <d...@nonceword.org> wrote:

 

Unfortunately, the R7RS small language unmodified is *un*suitable for
the task of building R7RS Large in a number of ways

The term "unmodified" is not quite right, because whatever is valid in Small is valid in Large, but I understand what you mean and I can't think of a better alternative right now.  

This is the nub of the problem with R7RS small: it quite simply leaves
too much up to the whims of the implementor

I'd modify this language too:  "the constraints under which the implementor operates".

One of the first requirements of
R7RS Large should therefore have been to tighten up R7RS and take some
of that flexibility away from implementors in exchange for real
guarantees for programmers.

I don't think it's necessarily the *first* thing to do, but it is something that needs doing, and I always knew that, but I didn't know just what it consisted of (and I don't think anyone fully does yet).

At the very least, ‘it is an error’ conditions in R7RS small which can
make it impossible to write applications processing untrusted input
with a guarantee of security ought to be tightened up to make a
practical Large language.

That's all of them, isn't it?

There are nearly 70 explicitly-named errors
causing undefined behaviour in R7RS small. Perhaps a dozen of these
can easily be seen to have security implications; there may be others
lurking in error conditions which are *not* explicitly named.
<https://github.com/johnwcowan/r7rs-work/blob/master/ItIsAnError.md>

Indeed there are, notably all the type errors like (car 2).

When WG2 awoke from its dormancy after the completion of R7RS small,
the chair immediately revised its charter in two significant ways:
firstly, the former restricted membership of WG2 was dissolved and
replaced by open participation of the whole Scheme community;

That's a valid characterization of what happened, but not of why I did it.  The original WG2 membership was self-appointed just like the present membership.  My concern was that so much time had passed that the original votes no longer could be considered binding, and I thought it appropriate for more people to join if they wished to.

secondly, the R7RS process was re-oriented around the existing SRFI
process, so that all proposals either had to come from SRFIs or,
unmodified, from the R6RS.

Another misleading truth: the SRFI basis was already in place, though only a few SRFIs had been voted in.

The SRFI-based process does not take account of the need to create a
self-consistent language (‘Self consistency is an important objective’
according to the WG2 charter),

It is, but I know of no process for achieving it for any document larger than R6RS, and I cannot swear the R6RS is self-consistent either.

which has already led to a debate over
the name of cut/cute and <>/<...> from SRFI 26

There is no way to guarantee the absence of debate, particularly when some participants believe that anything is free to be changed at any time until some future global freeze, possibly a decade or more from now.

after SRFI 26 was
already accepted not only in principle, but (theoretically) in exact
specification form. One reason for this is that it fails to allow
broader principles to be decided before fine details are worked out:
SRFIs must be complete specification documents with working
implementations.

What general principle controls the use of cut/cute or for that matter <>?  "Don't step on Prolog's use of `cut`, but do step on other people's use of "_" (something discussed and rejected in the SRFI discussion)? As far as I can see it is solely a matter of taste.

Another major reason the self-consistency of R7RS Large cannot be
guaranteed by the current process is because, as Marc Nieper-Wißkirchen
has said, while the choices of any one voter may add up to a consistent
language design, the weighted average of a large group’s choices will
probably not. The small process was able to resolve this issue by (a)
having a smaller, fixed-size committee and (b) use of a Condorcet voting
system so all proposals had the maximum possible approval of the group.
WG2 has thus far used majoritarian voting (in some cases, with de facto
run-offs, such as on the question of the string library).

I don't think voting methods had anything to do with it.  It was the constant editing and re-editing by Alex and I that brought it to what state of consistency it has.  But I at least, and I think everyone else, are not going to be able to do that kind of editing.

John Cowan has
explicitly stated that he does not intend to remove anything from an
‘Edition’ of R7RS Large which was voted into a previous ‘Edition’.
<https://srfi-email.schemers.org/srfi-discuss/msg/18004344/>

This requirement is unnecessary: there is no charter obligation for
non-final editions of R7RS Large to remain stable;

Editions are not drafts: they are tranches, which were not necessary for Small but are, in my judgement, necessary for Large because of its size.  (I don't believe that 2026 is plausible for the final tranche, though I may be wrong.)

A real example of such a consistency problem has been noted with the
order of arguments to the ‘kons’ procedure given to fold procedures.

It's not that big a deal.  The vector-like folds use one rule, all other folds another.  Similarly, the vector-like unfolds take a number of elements to unfold, all others use a stop? predicate.

Inequality of information is a sad reality of democracy, but for such a
small groups of voters to have such widely differing amounts of
information when casting their votes is a situation that can hardly even
be called democracy. It decreases the quality of decisions and makes
situations like poor and inconsistent libraries being adopted more
likely.

Well, there's a difference between information being unavailable (which is indeed undemocratic) and it being unconsidered by the voters.  A vote is never invalidated because voters didn't choose to take things into account.

The situation also makes it hard to understand and compile a rationale
for the inclusion of features or libraries, a very valued feature of
Scheme specifications so far — even of R6RS which was, like R7RS,
designed by voting rather than unanimous consensus.

We aren't in a position to collect rationales.

1. Open a new, single, centralized place for discussion of R7RS
development — both of new features and problems with the existing
language.

I don't object to this in principle: however, it's not clear what counts as a problem.  If one person says something is a problem, does that make it a problem?  We had 400+ issues in the development of Small; I would very conservatively expect an order of magnitude more for Large.

This should be set up inside proper project-management
software. Even GitHub or GitLab Issues would probably do

Historically we've gotten into difficulties if we use shared systems like Git{hub,lab} issues and we aren't able to create automatic backups.  You can extract issue data, but AFAIK you have to do it with the UI, which is easy to get wrong.  In addition, git and email are open source: GitHub isn't, and although someone can run their own GitLab instance, we can't be sure that it survives a loss of interest by the instance owner.

2. Establish eligibility criteria for proposals for R7RS Large. To
some extent, the requirement for the majority of proposals to be made
in the form of SRFIs does this; but general principles such as how
platform-specific operating system integration libraries should be,
and to what extent R6RS vs SRFI proposals should be preferred, remain
undefined.

So they do; I don't think we can define all rules in advance.

There is also no clear process for *proposing* smaller
corrections to adopted libraries which are not worth making into
independent SRFIs, and what backwards-compatibility requirements apply
to such corrections, hampering the process of cleaning up the small
language *and* the inconsistencies which have been found in the Large
language so far — this should be made clear.

Well we have the erratum/PFN process that I outlined.  It's true that there are no *explicit* rules for what can be an erratum, what can be a PFN and what cannot be either; "ask the SRFI editor" is currently the process, and it seems to work well.

 

(I personally have a list
of over fifty issues, mainly related to consistency, which I would
like to see addressed. I will enter them into the issue tracker if it
is opened.)

URL?

3. Work on the final specification document for R7RS Large should
begin already, in order to catch consistency issues as soon as
possible.[†] The editor should enter consistency issues etc. into the
issue tracker mentioned in proposal 1 as they arise.

By all means.  Who is volunteering to be the editor?

4. Consideration (!) should be given to re-establishing a WG2 core
committee of a small number of particularly active and knowledgeable
members with the power to adopt proposals by informal unanimous
consensus without waiting for a vote of the whole WG2 electorate.

Okay, time for me to draw a line: if such a "Committee of Public Safety" were to be appointed, which of course the WG and the SC are well entitled to do, I would find it necessary to resign as chair.  I am absolutely opposed to such oligarchy.  What I 

*might* accept would be the "pre-1795 Polish Sejm" system, in which a small de-facto group makes decisions, but any member of the larger group can override that by shouting "Veto!", in which case the question goes to a full vote.  Hopefully we will not be destroyed by Russia, Prussia, and Austria because we are always deadlocked by this.

As one final note, I should say that I have continued confidence in

John Cowan personally as chair.'

Thank you; I appreciate your (qualified) support.

 

[†] Recent complaints in the #scheme IRC channel about the difficulty of
producing a hypertext version of the R7RS small report suggest that the
master source of this document should *not* be in TeX. Of course, the
PDFs of the Scheme reports look as slick as they do because of TeX;
but a printed version could be produced by converting another markup
language into TeX source.

The TeX source *is* hypertext, by the way. though it's not HTML.

[Arthur A. Gleckler]

On Tue, Feb 22, 2022 at 12:13 AM Vincent Manis <vman...@gmail.com> wrote:

 

When the Red docket was voted on, I tried to produce a consolidated specification document. I distributed it here, and got zero feedback (apart from a valuable correction to my mistaken ideas about SRFI copyrights). I didn't think it was very good, in particular, there was no coherent outline, and little notational consistency. However, I hoped it would stimulate discussion about what a final R7RS-Large might look like. I haven't seen that discussion.

 

I apologize for not sending feedback myself.   I read the document, and consider it a big contribution, but other work kept getting in the way of my doing a thorough review, and I never got around to it.  I will certainly review the R7RS Large draft, then that day comes, with a fine-toothed comb, as they say.

[Arthur A. Gleckler]

On Tue, Feb 22, 2022 at 8:50 PM John Cowan <co...@ccil.org> wrote:

 

4. Consideration (!) should be given to re-establishing a WG2 core
committee of a small number of particularly active and knowledgeable
members with the power to adopt proposals by informal unanimous
consensus without waiting for a vote of the whole WG2 electorate.

Okay, time for me to draw a line: if such a "Committee of Public Safety" were to be appointed, which of course the WG and the SC are well entitled to do, I would find it necessary to resign as chair.  I am absolutely opposed to such oligarchy.  What I *might* accept would be the "pre-1795 Polish Sejm" system, in which a small de-facto group makes decisions, but any member of the larger group can override that by shouting "Veto!", in which case the question goes to a full vote.  Hopefully we will not be destroyed by Russia, Prussia, and Austria because we are always deadlocked by this.

I agree completely with John on this point.   While Daphne, Marc, et al. have raised some good points about the R7RS Large process, I strongly oppose the kind of centralization of power recommended here.  While I participated in R6RS, I know prominent, long-term members of the Scheme community who didn't, and it was largely because it operated in a similarly closed manner.  All previous RnRS versions had been produced by consensus, and the change in how R6RS was developed left them feeling cast aside.  I don't want to see that happen again.

[Vincent Manis]

On 2022-02-22 7:42 p.m., Arthur A. Gleckler wrote:

I agree completely with John on this point.   While Daphne, Marc, et al. have raised some good points about the R7RS Large process, I strongly oppose the kind of centralization of power recommended here.  While I participated in R6RS, I know prominent, long-term members of the Scheme community who didn't, and it was largely because it operated in a similarly closed manner.  All previous RnRS versions had been produced by consensus, and the change in how R6RS was developed left them feeling cast aside.  I don't want to see that happen again.

I don't want my earlier comments to be interpreted as favoring oligarchy. Consensus is essential to the acceptance of R7RS-Large, and a key element of that is transparency. That said, we can impose somewhat more structure on the process, by having one of our focuses (foci?) be the final Report.

The genius of the existing Reports is their fulfillment of the famous St-Exupéry quote about perfection involving nothing left to take away. I would be happy if the final R7RS-Large Report exhibits the same unity and consistency, while still defining a powerful language.

-- vincent

[Daphne Preston-Kendal]

> --
> 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/CAD2gp_T0wQhKTQSOtTKEd-jaZ5pWKDjx5nwWik49CoLAdd8stw%40mail.gmail.com.

[Marc Nieper-Wißkirchen]

I strongly disagree with this interpretation. What Daphne proposes is
not oligarchy; it would be if the Scheme community wasn't allowed at
least final ratification votes and the right to return the draft to
the working group for changes for the better.

In fact, what Daphne describes is how a modern democratic system
works, at least this is how it goes in my country; it's mostly the
government that prepares the legal texts and the de facto rôle of the
parliament is to decide on essentially final versions.

R6RS has been criticized in view of the process that was used to
create it. R6RS is certainly not perfect but I claim that it is the
best one that one was able to achieve given the goals that were set
for it.

Moreover, even a process as was used by R7RS-small doesn't guarantee a
different outcome than R6RS had. Most of the supporters of R6RS simply
abstained from voting on R7RS and that part of the community is still
mostly absent from the R7RS-large process, so even with a "more
democratic process" (whatever this means), we won't gain a wider
acceptance. We should probably just accept this fact; every
specification larger than the minimal R4RS will have to make
compromises (the more the larger the specification), so it will
alienate people who think who can't back decisions that led to the
specification.

Allow me to use the following analogy: A good book is usually only
written by very few authors; the potential readers do not usually have
a final say what goes in which chapter. And yet, it is fully
democratic. It is the potential readers that finally have the power
(by reading/buying the book or not) to decide whether the book is a
success or not.

There are a lot of other points, I would like to say something about
(and I probably will), but getting the above right (in my point of
view) I found most important.

Marc

[Daphne Preston-Kendal]

(Apologies for the previous mail which contained nothing more than a quote of John’s reply, the result of accidentally clicking ‘send’ before actually having typed anything. Note to self: don’t try to use a computer that early in the morning.)

On 23 Feb 2022, at 2:50, John Cowan wrote:

>> At the very least, ‘it is an error’ conditions in R7RS small which can
>> make it impossible to write applications processing untrusted input
>> with a guarantee of security ought to be tightened up to make a
>> practical Large language.
>
> That's all of them, isn't it?

Anything related to syntax has very little security relevance in this sense, for example. (That’s not to say we shouldn’t give some consideration to cleaning that up too.)

>> When WG2 awoke from its dormancy after the completion of R7RS small,
>> the chair immediately revised its charter in two significant ways:
>> firstly, the former restricted membership of WG2 was dissolved and
>> replaced by open participation of the whole Scheme community;
>
> That's a valid characterization of what happened, but not of why I did it.
> The original WG2 membership was self-appointed just like the present
> membership. My concern was that so much time had passed that the original
> votes no longer could be considered binding, and I thought it appropriate
> for more people to join if they wished to.

I did not write anything about your intention behind the change, which I don’t object to in principle (see below). Perhaps I inadvertently implied otherwise, though.

> It is, but I know of no process for achieving it for any document larger than R6RS

Taking inconsistencies seriously when reported would be a good start.

> and I cannot swear the R6RS is self-consistent either.

I’m sure it isn’t, but at least they took consistency seriously. (Public comments on the R6RS drafts were, contra popular belief, seemingly taken very seriously and largely addressed by the final draft. Not a few of those issues concerned consistency.)

>> John Cowan has
>> explicitly stated that he does not intend to remove anything from an
>> ‘Edition’ of R7RS Large which was voted into a previous ‘Edition’.
>> <https://srfi-email.schemers.org/srfi-discuss/msg/18004344/>
>>
>> This requirement is unnecessary: there is no charter obligation for
>> non-final editions of R7RS Large to remain stable;
>
> Editions are not drafts: they are tranches, which were not necessary for
> Small but are, in my judgement, necessary for Large because of its size.

Can they not be both? „Was kümmert mich mein Geschwätz von gestern? Nichts hindert mich, weiser zu werden.“

> (I don't believe that 2026 is plausible for the final tranche, though I may
> be wrong.)

I admit it’s ambitious. It’s true we run out of finished SRFIs once the Orange Docket is done, but my impression is also that the non-SRFI proposals are in a better state than ever before. (More of them have implementations than ever before, for instance.)

>> A real example of such a consistency problem has been noted with the
>> order of arguments to the ‘kons’ procedure given to fold procedures.
>
> It's not that big a deal. The vector-like folds use one rule, all other
> folds another.

Such gratuitous inconsistencies make it harder to learn Scheme and harder for experienced programmers to keep the language in their heads. At best, they’re papercuts while programming; at worst, they make the language a laughing stock. Further, it’s not consistently so, even if one did think that were the rule, as streams, which are not vector-like, fold in SRFI 43 style, and strings and texts (which are more vector-like than list-like) fold in SRFI 1 style.

In the case of fold — the ‘fundamental iterator’ — the inconsistency also makes it impossible to use higher-order procedures taking fold procedures as arguments as ad-hoc generic iteration solutions. (This is the exact context in which I discovered this issue.)

This kind of thing is the problem with the SRFI process: there is too much left to the whims of the individual authors, who have historically all too often imposed their own idiosyncratic stylistic preferences distinct from existing precedent, which leads to inconsistencies. (Olin Shivers thought fold should work one way; Taylor Campbell thought it should work a different way, and silently changed it (intentionally or not). R7RS Large should be free to bring such idiosyncrasies into line in its versions of SRFI libraries in the (scheme …) namespace.

> Similarly, the vector-like unfolds take a number of
> elements to unfold, all others use a stop? predicate.

That distinction is less gratuitous, as it’s motivated by the fixed-length nature of most vector data types. (Flexvectors, which are not fixed in length, fold in SRFI 43 style but unfold in SRFI 1 style. Pvectors will probably do the same, when I get to implementing those procedures.)

>> 1. Open a new, single, centralized place for discussion of R7RS
>> development — both of new features and problems with the existing
>> language.
>
>
> I don't object to this in principle: however, it's not clear what counts as
> a problem. If one person says something is a problem, does that make it a
> problem?

Yes. As I said, ‘won’t fix’ is a valid resolution.

>> This should be set up inside proper project-management
>> software. Even GitHub or GitLab Issues would probably do
>
> Historically we've gotten into difficulties if we use shared systems like
> Git{hub,lab} issues and we aren't able to create automatic backups. You
> can extract issue data, but AFAIK you have to do it with the UI, which is
> easy to get wrong. In addition, git and email are open source: GitHub
> isn't, and although someone can run their own GitLab instance, we can't be
> sure that it survives a loss of interest by the instance owner.

Fine, something other than GH/GL Issues. That was intended as a minimal proposal which we could get started with quickly.

Gitea seems to offer the possibility for automated backup:
<https://docs.gitea.io/en-us/backup-and-restore/>

>> There is also no clear process for *proposing* smaller
>> corrections to adopted libraries which are not worth making into
>> independent SRFIs, and what backwards-compatibility requirements apply
>> to such corrections, hampering the process of cleaning up the small
>> language *and* the inconsistencies which have been found in the Large
>> language so far — this should be made clear.
>
>
> Well we have the erratum/PFN process that I outlined. It's true that there
> are no *explicit* rules for what can be an erratum, what can be a PFN and
> what cannot be either; "ask the SRFI editor" is currently the process, and
> it seems to work well.

Now I’m even more confused about the rôle of errata and PFNs. Some questions: Is reference-barrier still an optional export from (scheme ephemeron), even if it is now mandatory in (srfi 124)? Are pairs and ipairs now allowed to belong to the same type in (scheme ilist), like they are in the amended (srfi 116)? We haven’t voted on either of those as WG2 since the changes were made — the latter is a very good change (indeed, I think it should be mandatory and the whole library recast in those terms), but also very dramatic.

In any case, I maintain that doing all of this by PFN only leaves too much up to the whims of the SRFI editors and authors alone.

>> (I personally have a list
>> of over fifty issues, mainly related to consistency, which I would
>> like to see addressed. I will enter them into the issue tracker if it
>> is opened.)
>>
>
> URL?

~/Projects/r7rs-issues.org

Although I initially started gathering consistency issues on my Ultraviolet Docket page, I don’t see the point in posting these issues if there’s nowhere they can be discussed by all WG2 participants. Many of them have multiple different possible resolutions. Some of them will require input from implementers on how they could best solve the issue considering their own existing codebases. If they will simply sink into a mailing list and be forgotten in six months, there’s little point in raising them.

Even problems that are acknowledged in SRFIs with the remark that they were intended to be corrected in the versions adopted in the Red Edition have seemingly been adopted in *un*corrected versions. (See what SRFI 113 has to say about the order of arguments to set-map and set-unfold. The Red Edition, to my knowledge, did not actually explicitly fix that, and at least Chibi’s versions of the relevant libraries in the (scheme …) namespace exhibit the problem.)

[quoted from earlier:]

> I don't think voting methods had anything to do with it. It was the
> constant editing and re-editing by Alex and I that brought it to what state
> of consistency it has. But I at least, and I think everyone else, are not
> going to be able to do that kind of editing.

> [snip]

>> 3. Work on the final specification document for R7RS Large should
>> begin already, in order to catch consistency issues as soon as
>> possible.[†] The editor should enter consistency issues etc. into the
>> issue tracker mentioned in proposal 1 as they arise.
>
> By all means. Who is volunteering to be the editor?

As some point, we will need an editor. I’m somewhat concerned by this flippancy about the lack of one. Is there anyone qualified in WG2 who has enough time and resources to dedicate to this task, even if not immediately?

(I feel we should also gratefully note here the sterling work of Arthur Gleckler as de facto editor of most of the new specs going into R7RS, as the SRFI editor. I don’t intend to imply by this that I’m nominating him for this, undoubtedly larger task.)

>> 4. Consideration (!) should be given to re-establishing a WG2 core
>> committee of a small number of particularly active and knowledgeable
>> members with the power to adopt proposals by informal unanimous
>> consensus without waiting for a vote of the whole WG2 electorate.
>
> Okay, time for me to draw a line: if such a "Committee of Public Safety"
> were to be appointed, which of course the WG and the SC are well entitled
> to do, I would find it necessary to resign as chair. I am absolutely
> opposed to such oligarchy. What I
> *might* accept would be the "pre-1795 Polish Sejm" system, in which a small
> de-facto group makes decisions, but any member of the larger group can
> override that by shouting "Veto!", in which case the question goes to a
> full vote.

I did not intend to suggest abolishing the vote of the whole community, so something like this was meant to be implied, because some kind of clear relationship between open vote of the whole and consensus of the few would be needed. The purpose of the committee would be expediency and efficiency, not dictatorship of the few. The difference between Cabinet and Parliament in the Westminster system is, to some extent, a reasonable analogy.

> Hopefully we will not be destroyed by Russia, Prussia, and
> Austria because we are always deadlocked by this.

As WG2’s (adoptive) resident of Prussia, I will do my best to try to avoid that happening.


Daphne

[Dr. Arne Babenhauserheide]

Marc Nieper-Wißkirchen <marc....@gmail.com> writes:

> Am Mi., 23. Feb. 2022 um 02:50 Uhr schrieb John Cowan <co...@ccil.org>:
>> I
>> am absolutely opposed to such oligarchy. What I
>> *might* accept would be the "pre-1795 Polish Sejm" system, in which
>> a small de-facto group makes decisions, but any member of the larger
>> group can override that by shouting "Veto!", in which case the
>> question goes to a full vote. Hopefully we will not be destroyed by
>> Russia, Prussia, and Austria because we are always deadlocked by
>> this.

> Allow me to use the following analogy: A good book is usually only
> written by very few authors; the potential readers do not usually have
> a final say what goes in which chapter. And yet, it is fully
> democratic. It is the potential readers that finally have the power
> (by reading/buying the book or not) to decide whether the book is a
> success or not.

I think that this analogy does not apply here, because most authors have
alpha-readers, beta-readers, and editors (so there is early input from
concerned groups), and because while readers can easily ignore one book,
the Scheme-specification cannot easily be ignored once the
implementation you use adopts it.

In a legislative process there are usually several stages:

- discussion with relevant and affected groups¹ to collect goals and requirements
- creating different drafts in different groups (many never published,
some held back for later)
- creating a concrete proposal and circulating it
- discussing change requests to get them consistent (some building on
non-published ideas)
- putting the proposal to the vote in parliament, usually alongside
change-requests
- applying the changes voted in (hopefully not breaking the proposal)
- starting drafts for the next proposal to address errors in the current one

I’m not saying that this is perfect. What I think useful is to keep
thinking in stages:


requirements: We currently have SRFI’s and we’re voting them in. This
sounds most similar to the goals and requirements stage. Note that these
rarely make it into law unchanged².

draft: The next stage would be to put together a complete draft of the
points collected so far. Basically: “This is what r7rs-large would look
like if we stopped now”.

consistency: After that would come gathering required changes to get it consistent³.
This stage has a higher barrier of entry, because it strictly requires
participants to read and analyze the whole document. (note that we’re
not creating a single law but the whole rulebook)
Then creating a proposal for the draft with the changes applied (with a diff?).

gather change-requests: The next would be gathering change-requests against the
proposal in a more open way (people reading the consistent document and
noting everything they would like to see changed).

vote on changes: Then a vote which changes to apply.

vote on the draft: Finally a vote whether the current state should be
adopted as common step.

recurse on requirements: Then collecting items for the next step
started early, but I feel like the other steps are hard not visible
right now).


How can we contribute best to later stages?


Best wishes,
Arne

¹: and lobbyism and corruption …
²: except with lobbyism and corruption …
³: consistency and ease of discovery are the main advantages I see in
r7rs-large over SRFIs
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[Dr. Arne Babenhauserheide]

"Arthur A. Gleckler" <a...@speechcode.com> writes:

> I apologize for not sending feedback myself. I read the document, and consider it a big contribution, but other work kept getting in the way of my doing a thorough review,
> and I never got around to it. I will certainly review the R7RS Large draft, then that day comes, with a fine-toothed comb, as they say.

Same here, but I completely missed the email. Sorry for that.

Best wishes,
Arne

[Linas Vepstas]

Some remarks about JSON.

On Mon, Feb 21, 2022 at 11:13 PM Vincent Manis <vman...@gmail.com> wrote:

[...]  and then we'll have a collection of SRFIs with no conceptual unity.

For example, I have serious reservations about including JSON support in the language, not because I disapprove of the SRFI, but because JSON is currently a flavor du jour, and might well become less important in the future (and in any case, I don't understand the rationale for supporting JSON but not YAML or TOML, at least on input).  JSON support is important, at a practical level; but I'm not convinced it needs to be an integral part of the language. 

JSON (and YAML and TOML) is a way of representing data as lists of {fieldname:value} pairs, or key-value pairs.  It should be contrasted with tables (records)  where you have a header-record that holds all the field-names, followed by a collection of rows (records) all having the same structure as the header.

The table/record style is advantageous when you have lots of records, all having the same "shape". The JSON/YAML/TOML style is advantageous when you have only a handful of records, all with different "shapes". Explicitly providing field-names in JSON removes much of the headache of using records. Yet, on the other hand, if you have more than a dozen or two blobs of data to store, JSON is very inefficient in RAM and disk.

There is a third possibility, oddly overlooked: s-expressions. If you treat the first item after the open paren as a "record type", then you know the structure of the rest of the expression.  (shades of $vau)  Unlike JSON, you do not have to give the name of every field, explicitly; the field names are "anonymous".  So, thus, much like records. But unlike tables, s-expressions are easier to write; you can use them in an ad hoc manner.

It would be pretty interesting to have some sort of "conceptual unity" for all three styles of data representation, although I guess this is a tall task, in which few are interested.

-- Linas

[Marc Nieper-Wißkirchen]

Am Mi., 23. Feb. 2022 um 09:30 Uhr schrieb Dr. Arne Babenhauserheide
<arne...@web.de>:

>
>
> Marc Nieper-Wißkirchen <marc....@gmail.com> writes:
>
> > Am Mi., 23. Feb. 2022 um 02:50 Uhr schrieb John Cowan <co...@ccil.org>:
> >> I
> >> am absolutely opposed to such oligarchy. What I
> >> *might* accept would be the "pre-1795 Polish Sejm" system, in which
> >> a small de-facto group makes decisions, but any member of the larger
> >> group can override that by shouting "Veto!", in which case the
> >> question goes to a full vote. Hopefully we will not be destroyed by
> >> Russia, Prussia, and Austria because we are always deadlocked by
> >> this.
>
> > Allow me to use the following analogy: A good book is usually only
> > written by very few authors; the potential readers do not usually have
> > a final say what goes in which chapter. And yet, it is fully
> > democratic. It is the potential readers that finally have the power
> > (by reading/buying the book or not) to decide whether the book is a
> > success or not.
>
> I think that this analogy does not apply here, because most authors have
> alpha-readers, beta-readers, and editors (so there is early input from
> concerned groups), and because while readers can easily ignore one book,
> the Scheme-specification cannot easily be ignored once the
> implementation you use adopts it.

I didn't say that anything should happen in isolation. Of course,
getting feedback often and early can be crucial.

In any case, it does not seem to touch the point that was made.

[John Cowan]

On Tue, Feb 22, 2022 at 12:13 AM Vincent Manis <vman...@gmail.com> wrote:

For example, I have serious reservations about including JSON support in the language, not because I disapprove of the SRFI, but because JSON is currently a flavor du jour, and might well become less important in the future

"Past performance is no guarantee of future results", as the warning in stock prospectuses says.  And no technology lasts forever: IEEE floats might well become less important in the future.

(and in any case, I don't understand the rationale for supporting JSON but not YAML or TOML, at least on input). 

Two reasons: JSON is a ECMA standard as well as an RFC, and JSON is far more widely adopted.  YAML and TOML were basically designed by individuals and are supported by a random selection of projects: there is only de facto standardization for them.

So what I guess I'm saying is that there are facilities that are important, but are not key to the language.

"Keys to the language" are what R7RS-small, or even more narrowly (scheme base), are meant to be about.

I would strongly recommend that we pause voting on dockets, and proposing SRFIs, to plan out the shell of a final Report into which we could fit the currently-approved proposals, as well as those we expect to consider.

I call for a volunteer to do that ("who bells the cat?"), because I don't see it as being me.  The Straw Polls are meant to sample voter opinion about pre-SRFIs that don't yet have sample implementations, since in general those are the big bottlenecks to SRFI production.  The Urania Straw Poll got only 9 voters, and I am uneasy about rejecting a proposal by 3 votes to 2 or the like, so I am going to reopen that poll later.

[Linas Vepstas]

On Mon, Feb 21, 2022 at 1:39 PM Daphne Preston-Kendal <d...@nonceword.org> wrote:

 
And finally,
4. Consideration (!) should be given to re-establishing a WG2 core
committee of a small number of particularly active and knowledgeable
members with the power to adopt proposals by informal unanimous
consensus without waiting for a vote of the whole WG2 electorate.

 I would happily delegate my "vote" to one of a handful of people whose opinions I've come to enjoy & trust. This is in the spirit of "liquid democracy": rather than abstaining on the 90% of issues that I don't care about, I'd equally well write in "whatever Daphne said" or "whatever Marc said".  In other words, allowing someone else to cast a vote for me, for the 90% of the issues I cannot develop an opinion on.

-- linas

[John Cowan]

On Thu, Feb 24, 2022 at 2:29 PM Linas Vepstas <linasv...@gmail.com> wrote

 

There is a third possibility, oddly overlooked: s-expressions. 

We have two proposals, Pose and Twinjo.  Pose is a common subset of S-expressions in all the Lisps; it is also easy to implement in any other language as well.   It supports strings, numbers, a limited range of symbols (only a limited range of punctuation and lower-case ASCII letters are allowed and there is no symbol escape character), proper lists, and comments.

Twinjo has two formats, Twinjo Text and Twinjo Binary.  Twinjo Text primitive syntaxes provide integers, floats, symbols (with vertical-bar support), strings, bytevectors (wrapped in braces for compactness), proper lists, and comments.  Any of these can be prefixed by a tag, which begins with # and names a type.  There are about 40 standard tags in Twinjo: e,g, the character A is encoded not with an idiosyncratic syntax but with the tagged string #char"A".  Twinjo Binary is an ASN.1 encoding allowing a subset of the Basic Encoding Rules.

[Dr. Arne Babenhauserheide]

Is there some way to finance that? I remember reports about people
getting funding to work on commonlisp specifications. Something like
that for Scheme could enable doing this in a much stronger way.

[Amirouche Boubekki]

Re democratic system: I agree with Arne Babenhauserheide replies.

> Difficulty of Sharing and Keeping Track of Information

That is a major pain point.

> establishing WG2 core

There is already a WG2 core, albeit informal.

> JSON support in the language

On that topic, it is difficult to draw the line. I started with
SRFI-180, then I thought it was missing some stuff. Then we could
provide a generic tooling to work with s-expression (e.g. parsing,
traversal). Eventually, I rewrote portably SRFI-180 with just
`json-read` and `json-write`.

> When the Red docket was voted on, I tried to produce a consolidated
> specification document.

I did not contribute, because tex / latex is the wrong tool.

> I would strongly recommend that we pause voting on dockets, and
> proposing SRFIs, to plan out the shell of a final Report into which
> we could fit the currently-approved proposals, as well as those we
> expect to consider.

+1

> 3. Work on final specification document for R7RS Large

I need to be supported financially to work full time on it.

ref: https://scheme.rs/
ref: https://github.com/scheme-live/
ref: https://groups.google.com/g/scheme-reports-wg2/c/j5J7KTFa9vg/m/fTKnxrgHBwAJ

[John Cowan]

On Thu, Feb 24, 2022 at 6:08 PM Dr. Arne Babenhauserheide <arne...@web.de> wrote:

Is there some way to finance that? I remember reports about people
getting funding to work on commonlisp specifications. Something like
that for Scheme could enable doing this in a much stronger way.

<http://www.nhplace.com/kent/Papers/cl-untold-story.html> is partially about how CL got funded.  I don't believe the present situation of Scheme is in any way similar to the situation of Maclisp dialects in the early 1980s: there is no funding 3source corresponding to Arpa that wanted to make sure existing Lisps on different hardware platforms were compatible.

[Martin Rodgers]

On 26/02/2022, John Cowan <co...@ccil.org> wrote:

> <http://www.nhplace.com/kent/Papers/cl-untold-story.html> is partially
> about how CL got funded. I don't believe the present situation of Scheme
> is in any way similar to the situation of Maclisp dialects in the early
> 1980s: there is no funding 3source corresponding to Arpa that wanted to
> make sure existing Lisps on different hardware platforms were compatible.

We can still find some points of relevance. For example, the paragraph
in section 5.3 containing the line, "Aesthetic considerations shall
also be weighed, but as subordinate criteria", has some relevance to
the consistancy question, and perhaps some other questions discussed
in this thread.

Section 5.4 also has some interesting experience to offer.

Thanks for the link.

[John Cowan]

On Sat, Feb 26, 2022 at 4:55 AM Martin Rodgers <mcro...@gmail.com> wrote:

 

We can still find some points of relevance.

Oh, certainly.  I was addressing just the matter of funding and why IMHO we can't expect any from disinterested parties.

[Amirouche Boubekki]

> 1. Open a new, single, centralized place for discussion of R7RS
> development — both of new features and problems with the existing

> language. This should be set up inside proper project-management
> software. Even GitHub or GitLab Issues would probably do. Its use
> should be mandatory for people raising issues and making proposals for
> things to be added to the Large language: no proposal is eligible to
> be voted on or included which has not been made in the project
> management system.[*] R7RS Large is done when all tickets in the
> project management system have been closed (possibly as ‘won’t fix’),
> and not done before all tickets are closed. When ballots are voted on,
> each item should be linked to the relevant issue with its discussion
> thread so voters can see all the arguments for and against the
> proposals. (Voting could even take place over the project management
> system instead of over Google Forms as at present, also potentially
> removing the arguably-artificial requirement to wait for a docket to
> be finished before deciding on an issue.)
>

> [*] That is, proposing e.g. that a SRFI be adopted, not proposing a
> library which should itself be a SRFI. The existing forums for pre-SRFI
> proposals and their discussions are probably adequate.

We already tried small, and wanna be big, in many forms, and many
times. The latest, and possibly the last as far as I am concerned, is
scheme-live at https://github.com/scheme-live/live

Positive and negative feedback are welcome.

[Amirouche Boubekki]

> 3. Work on the final specification document for R7RS Large should
> begin already, in order to catch consistency issues as soon as
> possible.[†] The editor should enter consistency issues etc. into the
> issue tracker mentioned in proposal 1 as they arise.

That was clearly the goal when I setup
https://git.sr.ht/~amirouche/scheme.rs hosted at https://scheme.rs/

> [†] Recent complaints in the #scheme IRC channel about the difficulty of
> producing a hypertext version of the R7RS small report suggest that the
> master source of this document should *not* be in TeX. Of course, the
> PDFs of the Scheme reports look as slick as they do because of TeX;
> but a printed version could be produced by converting another markup
> language into TeX source.

It is not the first time we try to convert r7rs spec [0] to html. I
made that comment that it is difficult to convert the .tex source to
html, and I think that when starting from scratch it might be possible
to make it easy. In other words, reworking the tex source to target
both html and pdf might work. The (wanna) be Portable Document Format
is the least interesting medium nowadays. We could aim for an
interactive book (such as the online probabilistic programming book I
can't recall the URL at this time). Toward that goal, starting with
.tex will require much more effort. In my experience, the best markup
is not markdown, or skribble but Manuel Serrano's Skribe [1], we could
start with sxml.

[0] https://github.com/johnwcowan/r7rs-spec
[1] https://www-sop.inria.fr/members/Manuel.Serrano/publi/jfp05/article.html

[Marc Nieper-Wißkirchen]

Am Mi., 23. Feb. 2022 um 04:42 Uhr schrieb Arthur A. Gleckler
<a...@speechcode.com>:

>> Okay, time for me to draw a line: if such a "Committee of Public Safety" were to be appointed, which of course the WG and the SC are well entitled to do, I would find it necessary to resign as chair. I am absolutely opposed to such oligarchy. What I *might* accept would be the "pre-1795 Polish Sejm" system, in which a small de-facto group makes decisions, but any member of the larger group can override that by shouting "Veto!", in which case the question goes to a full vote. Hopefully we will not be destroyed by Russia, Prussia, and Austria because we are always deadlocked by this.
>
>
> I agree completely with John on this point. While Daphne, Marc, et al. have raised some good points about the R7RS Large process, I strongly oppose the kind of centralization of power recommended here. While I participated in R6RS, I know prominent, long-term members of the Scheme community who didn't, and it was largely because it operated in a similarly closed manner. All previous RnRS versions had been produced by consensus, and the change in how R6RS was developed left them feeling cast aside. I don't want to see that happen again.

While I understand any reservations about this issue, I do not
necessarily share Arthur's conclusions. To be honest, many prominent
long-term members of the Scheme community haven't been participating
in the R7RS-large process although it is maximally open. Furthermore,
the changes that led to new versions up to and including R5RS were
minimal compared to the number of changes R6RS brought. Thus, arriving
by consensus was much easier for the Scheme versions before R6RS. I
don't want to argue about whether R6RS had to be such a big change,
but R7RS-large definitely is supposed to become the biggest extension
of an existing Scheme standard ever. We would be blind if we believed
that R7RS-large would become a product based on the consensus of the
Scheme community. It will be based on the consensus of those who
decided to take part. Now one can argue that those who decided for
themselves to not participate won't have a right to complain
afterward, but this misses the point in my opinion. Voting with one's
feet is also a kind of voting.

Actually, I think it is not that important which kind of group by
whatever means creates a Scheme standard draft the community will then
be allowed to vote on. In the end, it is important what's in the draft
and whether what's in the draft gets enough support from users and
implementers. I wouldn't even mind if we had two or three competing
drafts in the end so that there will be a meaningful choice between
different options which each consistent by itself.

If a community wants to build a new building, they will ask several
architects for a plan and will then select among the different designs
and one of the architects will be awarded the contract. What they
won't do is to start building the structure with a changing body of
several architects and with no common plan or idea how the end result
should look like. (Caveat: This is just a metaphor, possibly a bad
one, so please don't base your arguments on this metaphor.)

Anyway, I think the main point of Daphne here (she will correct me if
I'm wrong) is not establishing an "oligarchy" for its own sake but to
make sure that those working on the standard and having to make
decisions (after getting second opinions) share a common vision and a
common goal of what the final result should be like and are
well-informed about all the moving bits. With the ever-changing body
of voters and, to a lesser extent, people proposing and writing SRFIs,
I am in doubt about the existence of such a shared vision.

(Such a problem of diverging visions existed - according to my
readings of the transcripts of the working groups - when both the R6RS
and the R7RS(-small) project was started. After part of the R6RS
working group left and after the R6RS supporters left the R7RS
process, there was at least free rein for a good language standard in
each case. The alternative would have probably been R5RS.)

Marc

[Amirouche Boubekki]

> 4. Consideration (!) should be given to re-establishing a WG2 core
> committee of a small number of particularly active and knowledgeable
> members with the power to adopt proposals by informal unanimous

> consensus without waiting for a vote of the whole WG2 electorate. This
> would provide a realistic forum in which, for example, the large numbers
> of issues related to backward-compatible cleanup of the WG1 language to
> make it more suitable for WG2’s purposes could be resolved efficiently.
> It would also allow self-consistency issues to be resolved without
> resort to a ballot. The core committee should include people working on
> implementations of Scheme as well as people with a serious interest in
> writing software in Scheme (but I repeat myself /s).

Citation needed everywhere. Even if you can back up your claims about
what is a good project management enterprise with some amalgamation of
state-of-the-art serif glyphs whose copyright holders have credentials
in esteemed groups, relaying knowledge for centuries, and millenia to
mere mortals like we all are; even in that case, you will fall short
of the premise of why several schemers _dared_ to write, share
publicly, and sometime stress in spite of "no enough centrality [and
knowledge] in R7RS" their ideas of what progress could mean.

Even more so, you are very wrong about what makes a project succeed,
and how to improve the chance of success of R7RS.

> If sounds, grounds, ideas and understandings are echoing, don't overestimate their infinite reflection that might be aiming for an unforeseen dubious equilibrium, find your way out, escape the invisible tie knot, think on your own.
>
> Amirouche Amazigh ~ https://hyper.dev

[Amirouche Boubekki]

The conclusion of Arthur post is:

>> All previous RnRS versions had been produced by consensus, and the change in how R6RS was developed left them feeling cast aside. I don't want to see that happen again.

> While I understand any reservations about this issue, I do not
> necessarily share Arthur's conclusions.

I do not understand your answer to the conclusion.

> To be honest, many prominent
> long-term members of the Scheme community haven't been participating

To be factual, each has their own reasons.

> in the R7RS-large process although it is maximally open.

Each has their own reasons.

> but R7RS-large definitely is supposed to become the biggest extension
> of an existing Scheme standard ever. We would be blind if we believed
> that R7RS-large would become a product based on the consensus of the
> Scheme community. It will be based on the consensus of those who
> decided to take part.

That is the point of an open, and democratic process.

> Now one can argue that those who decided for
> themselves to not participate won't have a right to complain
> afterward, but this misses the point in my opinion. Voting with one's
> feet is also a kind of voting.

I do not understand how it relates to the previous "paragraph" that I
would paraphrase as:

R7RS is the consensus majority of those who vote.

Then:

> Actually, I think it is not that important which kind of group by

You contradict what you said above, you claim above that the R7RS WG2
will be better served by, paraphrasing:

core of knowledgeable, prominent people in Scheme community, and
implementers dubbed worth attention.

> whatever means creates a Scheme standard draft the community will then
> be allowed to vote on.

Later you add:

> I wouldn't even mind if we had two or three competing
> drafts in the end so that there will be a meaningful choice between

> different options which are each consistent by itself.

Suggesting that idea is counter-productive, and harmful given the
process that was agreed upon by SC and WG2.

> In the end, it is important what's in the draft
> and whether what's in the draft gets enough support from users and
> implementers.

I disagree with the idea: implementers' support should drive the RnRS
process. I disagree about cargo-cult backward compatibility.

It is part of the R6RS idea that a Scheme: MUST.

> If a community wants to build a new building, they will ask several
> architects for a plan and will then select among the different designs
> and one of the architects will be awarded the contract. What they
> won't do is to start building the structure with a changing body of
> several architects and with no common plan or idea how the end result
> should look like.

That is called competition, hence wasted effort, perpetuating the
wrong idea that: the fittest prosper. If I remember correctly that is
inspired from Darwin thinking, that is probably a fraction of what
happens in Nature, and can suggest a few facts any 12 year old knows
about that contradict the idea of the survival of the fittest but that
is off-topic [0].

[0] https://en.wikipedia.org/wiki/Survivorship_bias

The alternative is built on top of a discourse mosaic, and that is the
framework R7RS has chosen.

> (Caveat: This is just a metaphor, possibly a bad
> one, so please don't base your arguments on this metaphor.)

I do not understand the metaphor. There is a competition inside R7RS?

>
> Anyway, I think the main point of Daphne here (she will correct me if
> I'm wrong) is not establishing an "oligarchy"

So, it is about establishing an `"oligarchy"`.

> for its own sake but to
> make sure that those working on the standard and having to make
> decisions

> (after getting second opinions)

(srsly?)

> share a common vision and a
> common goal of what the final result should be like and are
> well-informed about all the moving bits.

Let there be light.

> With the ever-changing body
> of voters and, to a lesser extent, people proposing and writing SRFIs,
> I am in doubt about the existence of such a shared vision.

meh

> (Such a problem of diverging visions existed - according to my
> readings of the transcripts of the working groups - when both the R6RS

url?

> and the R7RS(-small) project was started. After part of the R6RS
> working group left and after the R6RS supporters left the R7RS
> process, there was at least free rein for a good language standard in
> each case. The alternative would have probably been R5RS.)

I do not understand the sentence starting "After part of ..." or I do
not understand the point of this "paragraph". Most prolly you do not
mean something like: "The democratic process tried, and failed, twice,
hence let's...".

> What the Israelites saw was an intimidating giant. In reality, the very thing that gave the giant his size was also the source of his greatest weakness. There is an important lesson in that for battles with all kinds of giants. The powerful and the strong are not always what they seem.”
>
> David and Goliath, Malcolm Gladwell

[Linas Vepstas]

On Sun, Feb 27, 2022 at 2:28 PM Amirouche Boubekki <amirouche...@gmail.com> wrote:

The conclusion of Arthur post is:

> To be honest, many prominent
> long-term members of the Scheme community haven't been participating

To be factual, each has their own reasons.

What are those reasons?

-- linas.