Fork still looms
15 views
Skip to first unread message
Lassi Kortela
Mar 10, 2022, 12:42:09 AM3/10/22
to scheme-reports-wg2
First of all, thanks to John for making a proposal.
I'm afraid it's still grounds for a fork. "Foundation Libraries",
"contributors", committees, sub-committees, work products... You'll
struggle to get high-energy people committed.
This is the organizational structure I envision:
- Put up a fork of the R6RS git repo, a mailing list, and a website. All
public.
- Gather an informal group of people.
- The group insists that a full implementation of the standard runs
practical R6RS and R7RS-small programs as-is.
- Otherwise, the group asks Scheme implementers early and often what
extra features they want (if any).
- The group moderates the disputes that ensue between implementers. Once
the dust settles, everyone agrees on what's in scope for the standard
and sticks to it.
- The group refactors and extended the R6RS TeX files into shape, until
both the group and implementers are happy with the details.
- The work is synchronized with R7RS-large in all aspects possible,
avoiding gratuitous incompatibility like the plague.
- Once implementers are happy, the final document is sent to the Scheme
Steering Committee.
- The Steering Committee will take it or leave it. A group that rejects
a document enjoying wide support from the major implementers won't be
taken seriously.
I'm afraid it's still grounds for a fork. "Foundation Libraries",
"contributors", committees, sub-committees, work products... You'll
struggle to get high-energy people committed.
This is the organizational structure I envision:
- Put up a fork of the R6RS git repo, a mailing list, and a website. All
public.
- Gather an informal group of people.
- The group insists that a full implementation of the standard runs
practical R6RS and R7RS-small programs as-is.
- Otherwise, the group asks Scheme implementers early and often what
extra features they want (if any).
- The group moderates the disputes that ensue between implementers. Once
the dust settles, everyone agrees on what's in scope for the standard
and sticks to it.
- The group refactors and extended the R6RS TeX files into shape, until
both the group and implementers are happy with the details.
- The work is synchronized with R7RS-large in all aspects possible,
avoiding gratuitous incompatibility like the plague.
- Once implementers are happy, the final document is sent to the Scheme
Steering Committee.
- The Steering Committee will take it or leave it. A group that rejects
a document enjoying wide support from the major implementers won't be
taken seriously.
Dr. Arne Babenhauserheide
Mar 10, 2022, 4:28:57 AM3/10/22
to scheme-re...@googlegroups.com, Lassi Kortela
Lassi Kortela <la...@lassi.io> writes:
> First of all, thanks to John for making a proposal.
>
> I'm afraid it's still grounds for a fork. "Foundation Libraries",
> "contributors", committees, sub-committees, work products... You'll
> struggle to get high-energy people committed.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
John Cowan
Mar 11, 2022, 12:12:00 AM3/11/22
to scheme-re...@googlegroups.com
On Thu, Mar 10, 2022 at 12:42 AM Lassi Kortela <la...@lassi.io> wrote:
This is the organizational structure I envision:
- Put up a fork of the R6RS git repo, a mailing list, and a website. All
public.
- Gather an informal group of people. [etc. etc. etc.]
[chair hat]
Go ahead and do all that. But *not* on the scheme-reports-wg2 mailing list or the rest of our infrastructure, please, which you are cluttering up with your posts. It seems clear to me that you aren't getting any support for your plan here, it no longer has anything to do with WG2, and nobody on this list or in the Scheme community generally responds well to threats.
[/chair hat]
Vincent Manis
Mar 11, 2022, 1:41:51 AM3/11/22
to scheme-re...@googlegroups.com, John Cowan
I will only support an effort to create a Scheme Foundation Whatever or
Medium if the goal is the production of a specification that directly
helps the Large effort, and if it doesn't slow that effort down. That
means that this project must only adopt proposals that are
non-contentious or that have already been approved under the existing
Large dockets (i.e., Foundation-Thingy [1] must be a subset of Large).
In particular, putting out proposed features as new SRFIs will only
delay the process, given how long SRFI finalization can take.
That said, nothing says that the Foundation Thingy report need be the
last word. By all means, label it an interim report, and if there are
further additions to Large that seem to be reasonable in Foundation,
they can be included in a subsequent revision. Anything done for the
Foundation-Thingy effort is work that will not be needed to be done for
Large.
I am struck by a resemblance of this approach to that of the various
CODASYL Cobol standards. They too offered multiple levels of the
language, and a given implementation was defined by which level it met.
Here a given Scheme system can be described as meeting R7RS-Small,
R7RS-Foundation-Thingy, or R7RS-Large, all with or without
implementation extensions. That seems modular enough for me.
So...if we can meet the requirements I mentioned above, I'm all for it.
-- vincent
[1] If this is going forward, we do have to come up with a good name;
“Foundation Language and Libraries” works for me, but it is too verbose.
Medium if the goal is the production of a specification that directly
helps the Large effort, and if it doesn't slow that effort down. That
means that this project must only adopt proposals that are
non-contentious or that have already been approved under the existing
Large dockets (i.e., Foundation-Thingy [1] must be a subset of Large).
In particular, putting out proposed features as new SRFIs will only
delay the process, given how long SRFI finalization can take.
That said, nothing says that the Foundation Thingy report need be the
last word. By all means, label it an interim report, and if there are
further additions to Large that seem to be reasonable in Foundation,
they can be included in a subsequent revision. Anything done for the
Foundation-Thingy effort is work that will not be needed to be done for
Large.
I am struck by a resemblance of this approach to that of the various
CODASYL Cobol standards. They too offered multiple levels of the
language, and a given implementation was defined by which level it met.
Here a given Scheme system can be described as meeting R7RS-Small,
R7RS-Foundation-Thingy, or R7RS-Large, all with or without
implementation extensions. That seems modular enough for me.
So...if we can meet the requirements I mentioned above, I'm all for it.
-- vincent
[1] If this is going forward, we do have to come up with a good name;
“Foundation Language and Libraries” works for me, but it is too verbose.
Wolfgang Corcoran-Mathe
Mar 11, 2022, 8:30:35 PM3/11/22
to scheme-reports-wg2
The only fork that seems to be looming is the one that Lassi is proposing,
since it seems clear to me that Daphne and Marc do want to try to improve
the existing Large effort. But, it seems to me, Lassi's fork not only doesn't
enjoy "wide support from the major implementers", it doesn't, in fact, exist.
Lassi, a lot of what you've written lately reminds me of what you wrote
last year about scheme-live (https://github.com/scheme-live/). Some of your
goals (fast-moving development, informal organization, etc.) seemed
well-suited to that project, and there was no talk at the time of co-opting
any existing Scheme standardization processes. Judging by the lack of
activity on that project, you seem to have moved your scheme-live goals
(social as well as technical) here, where I doubt they fit. I'm also puzzled
and worried by what seems like the much more confrontational attitude
you're taking. I'd like to know why you've chosen this route, and why you've
apparently turned your back on scheme-live. (This is off-topic enough
already, so feel free to contact me directly.)
Wolfgang
Daphne Preston-Kendal
Mar 12, 2022, 2:51:19 AM3/12/22
to scheme-re...@googlegroups.com
On 12 Mar 2022, at 02:30, Wolfgang Corcoran-Mathe <first.lor...@gmail.com> wrote:
> The only fork that seems to be looming is the one that Lassi is proposing,
> since it seems clear to me that Daphne and Marc do want to try to improve
> the existing Large effort.
At least from my perspective, you are right. I have no interest in a fork under any circumstances. (If I truly despaired of Scheme that much, I’d give up and move to Racket or Haskell or Smalltalk or something. Or just make my own language from scratch with none of the Scheme legacy behind it.)
> The only fork that seems to be looming is the one that Lassi is proposing,
> since it seems clear to me that Daphne and Marc do want to try to improve
> the existing Large effort.
As such, I’d like to thank John for putting his moderatorial foot down on these silly meaningless threats.
Daphne
Marc Nieper-Wißkirchen
Mar 12, 2022, 3:48:53 AM3/12/22
to scheme-re...@googlegroups.com
Am Sa., 12. März 2022 um 08:51 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:
perspective (-:). We (that is I and whoever feels the same) have
serious doubts that the current R7RS process will lead to a language
that is good and worthy enough to serve as the foundation for Scheme
programming in the large for years to come and will also be supported
by enough high-level implementations. But we have voiced these doubts
in the hope that discussion about these will improve the existing
effort and not increase the proliferation of more incompatible
standards or quasi-standards.
The starting point of all this was Daphne's letter. It's probably a
good time to look at the issues raised by her once more. The "R7RS
Medium" idea can be a solution to some of the problems, but not all.
Nevertheless, what I like about the "R7RS Medium" idea is that, when
successful, the following goals are achieved:
(1) We have a foundation for R7RS Large and that foundation is large
enough to sustain the Large language (as it has become increasingly
clear that R7RS Small is too small for that in a lot of regards).
(2) We get an intermediate language that can also serve as a
backward-compatible successor for R6RS also in terms of size, paving a
way for the R6RS people to the R7RS process.
(3) People like Lassi who want to see live libraries and not libraries
fixed by a standard can use this medium language as the basis of their
efforts. The R7RS Large process can always incorporate such "live
libraries" later in the large language.
(4) The same goes for purists who want Scheme to be still a diamond,
albeit a larger one. These will found their work on the medium
language and accept that other people would like more and the large
language.
(5) A medium language that is codified in a report like R6RS or R7RS
(small) can make the errata in R6RS and R7RS official (as part of it)
and can amend R6RS and R7RS (small) where there are incompatibilities
with the large language that have to be fixed anyway (e.g.
redefinition of bindings at the top-level).
We may have to talk back to the SC so that all these points can become
true. In any case, a medium language should serve as a unifier
(sitting between existing languages and the large language) and not
create another Scheme incompatible with the rest.
In defense of Lassi, let me remark that he said that had had to go
AWOL for a while, so we possibly cannot judge the success of the
Scheme Live project. I'm also not sure whether he used the word
"threat" necessarily in the same sense that many have understood it. I
think it is okay to use it in the sense of: "When you don't change the
R7RS Large project in the following ways..., there's a non-neglectable
threat that (part of) the Scheme community will create a rival
that..." What I take away from it is that we should try to be as
inclusive of ideas as we can as the whole Scheme community is already
tiny enough. The obvious conclusion to me is that the large language
will have to be larger than necessary (from a purist's point of view
or regarding redundancy) and that there should be a step between as
sketched above (which can also not be minimal).
Marc
<d...@nonceword.org>:
>
> On 12 Mar 2022, at 02:30, Wolfgang Corcoran-Mathe <first.lor...@gmail.com> wrote:
>
> > The only fork that seems to be looming is the one that Lassi is proposing,
> > since it seems clear to me that Daphne and Marc do want to try to improve
> > the existing Large effort.
>
> At least from my perspective, you are right. I have no interest in a fork under any circumstances. (If I truly despaired of Scheme that much, I’d give up and move to Racket or Haskell or Smalltalk or something. Or just make my own language from scratch with none of the Scheme legacy behind it.)
Yes, this is why we are discussing it here (at least from my
> On 12 Mar 2022, at 02:30, Wolfgang Corcoran-Mathe <first.lor...@gmail.com> wrote:
>
> > The only fork that seems to be looming is the one that Lassi is proposing,
> > since it seems clear to me that Daphne and Marc do want to try to improve
> > the existing Large effort.
>
> At least from my perspective, you are right. I have no interest in a fork under any circumstances. (If I truly despaired of Scheme that much, I’d give up and move to Racket or Haskell or Smalltalk or something. Or just make my own language from scratch with none of the Scheme legacy behind it.)
perspective (-:). We (that is I and whoever feels the same) have
serious doubts that the current R7RS process will lead to a language
that is good and worthy enough to serve as the foundation for Scheme
programming in the large for years to come and will also be supported
by enough high-level implementations. But we have voiced these doubts
in the hope that discussion about these will improve the existing
effort and not increase the proliferation of more incompatible
standards or quasi-standards.
The starting point of all this was Daphne's letter. It's probably a
good time to look at the issues raised by her once more. The "R7RS
Medium" idea can be a solution to some of the problems, but not all.
Nevertheless, what I like about the "R7RS Medium" idea is that, when
successful, the following goals are achieved:
(1) We have a foundation for R7RS Large and that foundation is large
enough to sustain the Large language (as it has become increasingly
clear that R7RS Small is too small for that in a lot of regards).
(2) We get an intermediate language that can also serve as a
backward-compatible successor for R6RS also in terms of size, paving a
way for the R6RS people to the R7RS process.
(3) People like Lassi who want to see live libraries and not libraries
fixed by a standard can use this medium language as the basis of their
efforts. The R7RS Large process can always incorporate such "live
libraries" later in the large language.
(4) The same goes for purists who want Scheme to be still a diamond,
albeit a larger one. These will found their work on the medium
language and accept that other people would like more and the large
language.
(5) A medium language that is codified in a report like R6RS or R7RS
(small) can make the errata in R6RS and R7RS official (as part of it)
and can amend R6RS and R7RS (small) where there are incompatibilities
with the large language that have to be fixed anyway (e.g.
redefinition of bindings at the top-level).
We may have to talk back to the SC so that all these points can become
true. In any case, a medium language should serve as a unifier
(sitting between existing languages and the large language) and not
create another Scheme incompatible with the rest.
In defense of Lassi, let me remark that he said that had had to go
AWOL for a while, so we possibly cannot judge the success of the
Scheme Live project. I'm also not sure whether he used the word
"threat" necessarily in the same sense that many have understood it. I
think it is okay to use it in the sense of: "When you don't change the
R7RS Large project in the following ways..., there's a non-neglectable
threat that (part of) the Scheme community will create a rival
that..." What I take away from it is that we should try to be as
inclusive of ideas as we can as the whole Scheme community is already
tiny enough. The obvious conclusion to me is that the large language
will have to be larger than necessary (from a purist's point of view
or regarding redundancy) and that there should be a step between as
sketched above (which can also not be minimal).
Marc
Lassi Kortela
Mar 13, 2022, 1:31:21 AM3/13/22
to scheme-re...@googlegroups.com
As requested, I sent Wolfgang a private reply; ask for copies if you like.
To clear up confusion around my goals for RnRS and Scheme Live, they
remain the same as ever. The two projects serve different purposes.
RnRS:
- formal implementer standard
- has a responsibility to cater to the whole Scheme community
- competitors detract from its value
- the project should take 2-3 years to publish one document, then disband
- as few new features as possible. "when in doubt, leave it out."
- have only proven features
Scheme Live:
- informal user standard (one of several)
- only responsible for catering to its own users
- competitors are fine, and may even add value
- the project should go on forever, publishing annual stable releases
- as many new features as possible. "when in doubt, add it in."
- have experimental features too
To clear up confusion around my goals for RnRS and Scheme Live, they
remain the same as ever. The two projects serve different purposes.
RnRS:
- formal implementer standard
- has a responsibility to cater to the whole Scheme community
- competitors detract from its value
- the project should take 2-3 years to publish one document, then disband
- as few new features as possible. "when in doubt, leave it out."
- have only proven features
Scheme Live:
- informal user standard (one of several)
- only responsible for catering to its own users
- competitors are fine, and may even add value
- the project should go on forever, publishing annual stable releases
- as many new features as possible. "when in doubt, add it in."
- have experimental features too
Reply all
Reply to author
Forward
0 new messages