Dear Scheme Steering Committee, dear all,
Having given the matter much thought, I would like to invite the
Scheme Steering Committee to consider me as a candidate for the next
chair of Scheme Working Group 2. I would like to make it clear up
front that my candidacy is provisional. Details below.
John Cowan has served WG2 excellently over the last decade. He
(correctly, in my view) considers the role of the chair to be
primarily one of facilitator, not of dictator (however benevolent). I
would aim to follow in his footsteps in this regard.
He is correct, however, that recent arguments about the direction of
the language have seemed to confirm the impression that it is
impossible to find consensus. As part of reflecting on whether to
offer myself for this position, I have of course also considered this
situation, its cause, its nature, and how it could be resolved. I
believe I bear some responsibility for the problems that have arisen,
as it was at my instigation that the procedural changes in WG2 were
made, mainly establishment of the central issue tracker, together with
structural changes in R7RS Large, namely the splitting of the report
into ‘Foundations’ and ‘Batteries’. The latter decision was, I think,
a good choice, and not at the core of the current conflicts: it has
more clearly defined what kind of language R7RS Large will be, and has
allowed those with more interest in core language semantics vs
standard libraries, respectively, to feel confident that the language
will embody their vision for it.
The establishment of the central issue tracker is, I reckon, more to
blame for the current disputes. The old model of periodic ballots
provided the community with focus; the issue tracker has the problem
that, since all currently outstanding problems are listed in one
place, any such problem can become a focus of attention at any time,
and then arguments about the details of that problem erupt. John has
observed in #scheme that the more into detail we get, the more we seem
to argue, which seems accurate. It has also, in practice, become a
place where issues related to the Foundations only are discussed, and
work on the Batteries has mostly stalled. Mea culpa!
Arguments about details aside, I observe that there is nonetheless
broad consensus among WG2 participants about the Large language will
look like, even what the Foundations will look like.
For example, the current focus of dispute is the relationship between
R6RS and R7RS Large. Marc Nieper-Wißkirchen has helpfully summarized
the possible options in terms of four possibilities of increasing
fidelity to R6RS, in this issue:
As Marc notes, option 1 is effectively no longer on the table. Given
options 2–4 *all* imply that we won’t do anything which would be
outright *incompatible* with R6RS, this implies sufficient consensus
that, in fact, the debate could be left until much later, and even
resolved (as a last resort, if absolutely necessary) by a
‘tie-breaking vote’ of the Steering Committee, at the time when the
first drafts of a complete and finished report are being done. It is,
at that point, merely a question of what goes in what library, not
what goes in the language as a whole.
What I am trying to say is: we know what the language will look like;
why are we arguing about small details, and what is holding us back
from further real progress? We are conscious of the ‘bikeshed
principle’ when it comes to obviously minor things like naming our
procedures and macros, but have nonetheless got bogged down in things
of not significantly greater importance.
I therefore propose to return to a model which I hope will give people
more focus, while retaining the advantages of the central issue
tracker. Namely, as chair I would immediately aim to start producing
the final report in the form of a series of fascicles dedicated to
different subject areas within the Foundations report. These fascicles
would, at least initially, define what functionality is in R7RS Large,
but not the library structure of the Foundations (yet). Merely putting
things into libraries can be done later, when both the big picture and
the small details are clear – and it is at this point when we can
consider whether we want to require vs allow support for the (rnrs
(6)) libraries as well, and similar matters. The text of the fascicles
would, after revision inspired by debate, voting, formal comment, etc.
etc., directly be incorporated into the eventual final report. More
pertinently, these fascicles, once released, would provide the working
group with points to focus on and hopefully see off the current chaos.
The first fascicle would be on syntax expansion, encompassing both
syntax-rules and syntax-case and the extensions R7RS will add to the
latter. This is the area where I think most consensus on extensions to
R6RS exists, and where the details that remain to be worked out will
be easiest to find ultimate agreement on. I would hope to complete a
first draft of this fascicle by the end of 2023. After that, we will
see what comes next. I will work out an order for the fascicles early
on, and try to stick to it.
It’s my understanding that John is happy to continue the Batteries
effort, which will be unaffected by my initial focus on the
Foundations report. I encourage him (and others) to continue proposing
new libraries, making them into SRFIs, and holding rainbow ballots on
their inclusion in the Batteries report. While it may seem odd to work
on them before the Foundations they work upon are done, quite detailed
proposals can be made and adopted on the basis of the small language.
When the Foundations are done, many will just need to be updated to
match the error condition system we specify (which will be
R6RS-compatible, as stated above). Anyone whose proposal needs
something the small language can’t accommodate can ask what the
Foundations will provide and work on that basis: for almost everything
of significance, there’s already a SRFI for it, or R6RS can be used as
a reference, or similar.
There remains one more issue of process I am seriously concerned
about, which is getting R7RS Large implemented. The small language
used Chibi as a testbed; the Large language still has nothing to use
in a similar way, and Chibi itself is probably not very well suited. I
have gathered a list of existing implementations which are candidates
for this role here: <https://codeberg.org/scheme/r7rs/issues/122
actually doing this will mean securing the agreement of the maintainer
of one of these implementations to keep up with the fascicles. Like
Alex Shinn for the small report, this person will essentially become a
headline editor of the final report(s): it’s a significant commitment.
As chair, I would reach out to maintainers and gauge their interest in
taking on this task. I would also look at the possibilities for
creating a brand new implementation to serve this purpose, in case no
implementor is currently able to commit their time to this job.
Acknowledging that the reference implementation would need to be quite
performant, this would probably entail using an existing language
platform such as Racket, RPython, WASM/Hoot, or similar. That would be
a last resort, however, compared to getting an existing implementation
I hope this analysis of the current problems facing WG2 is useful both
to the Steering Committee and to the next chair, even if the Committee
picks someone other than me.
Now we come to the proviso. I would want to do the position of chair
justice, but I already have quite a lot coming up at the moment. Some
of that other stuff can be put off, and in fact I would be grateful
for the opportunity to put it off. The main one cannot: besides
beginning the R7RS Large report, I will also be writing my bachelor’s
dissertation in historical-comparative linguistics this coming
semester. Nonetheless, I believe that if I could put off some
financial pressure so that I can delay the other things I mentioned, I
could do both.
This means I would only be willing to take on the role of chair if I
could receive a small stipend to support my work on the Large
language. Previous discussions of getting funding for WG2 have
generally ended at ‘wouldn’t it be nice if ...’. It seems hard to
identify potential sources of funding, but I would like to make a
Scheme occupies a privileged position within the realm of ‘obscure
languages’. Namely, it is still the vehicle for much programming
language research, especially in the field of control flow and and
hygienic macros. The former research has now come to the world of
‘mainstream’ functional programming through extensive work now being
done on algebraic effects in languages like Haskell; the latter has
even broken into mainstream programming full-stop through Rust.
Interest in programming language development is at an all-time high.
Scheme’s important role in history is already being shown.
My idea is to capitalize on this and ask especially companies that
have a strong interest in programming language innovations to
contribute a small amount. There are now many such companies: besides
those very closely associated with the Scheme community such as
Bevuta, there are examples such as Mozilla (Rust), Epic Games (Verse),
Microsoft (Haskell and now even Scheme in Excel) whose main business
isn’t in programming languages, but now have clear interests in their
development, and could possibly be persuaded to contribute regularly
to the standardization of R7RS Large as both codifying recent research
and providing a base for further development of programming language
technology, so that the standard language remains not far from the
cutting edge of research.
My needs are modest and would be met by even as little as 500€ a
month. (520€ per month at 40 hours per month is a standard offer to
students working on academic projects part-time in my university
department, and one I consider a good guideline for what I would
commit to as WG2 chair.) If the maintainer of the reference
implementation needs a stipend to support their engagement,
sponsorship could also fund their work. I also think it would be a
good idea to establish a fund for other Schemers who could use the
money to attend any potential face-to-face meetings, promote Scheme at
I can ask for sponsorship for myself, personally, but since I would
effectively be asking for it in the name of the Scheme Working Group,
and because I would like to establish a fund for the further
development of Scheme that will help other people than just me, I feel
I should let the Steering Committee know that I would intend to do
this. I am happy to submit to whatever reasonable accountability
procedures the Steering Committee would like to impose to ensure that
the money is distributed appropriately.
As a final organisatorial note, I would like to say that, because my
own schedule for that week is already full, there is no chance at all
that I could take John’s slot at ICFP.
All that remains for me to say is thank you to John for his decade of
work on R7RS Large. He has, after the saying, big shoes to fill. I
hope, if the Steering Committee were to select me, I would be a worthy
dpk (Daphne Preston-Kendal) ·· 12103 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
(yes, I used the same signature last year)