The starting point should be that it's implementation first (or
implementation and discussion), and once the implementation
stabilizes, a stable specification is the end product.
It's still the case that SRFIs work like that to a fair extent. The
main exception is the work that I'm doing: I have time to write specs
(and I enjoy writing them), whereas writing the corresponding code
requires not only more time than I have now, but quite possibly more
time than I will ever have.
I don't believe that the designer-driven approach is the right one. I
know you have invested a lot in to that approach, but there's no getting
around the issue that it's opposed to a lot of the received wisdom
around hacking and agile. Specs are wonderful, but they should be
produced iteratively with users in the loop. With no field testing
before finalization, the process is uncomfortably waterfall-like. This
is an argument that several experienced schemers have made about current
SRFI practice.
Whether one likes to write specs or not (I also enjoy writing them, so I
have stake in both sides of the argument) it would be good to have users
for libraries first, and then graduate those libraries to stable status
after users have deemed them stable, and this should be a slow process.
I do use the SRFIs I wrote, and while I think they turned out okay I'm
not satisfied with the process of how they were made and the fact that
changes can't be made to them anymore. I had too much power relative to
other people, and not enough time to arrive at the best design.
Scheme Live would fix these problems. Any given individual doesn't need
to have time for everything if it's a group effort. The beauty of the
approach is that the spec and code writers are also the main users.
I still don't understand why you are so drawn to finalizing specs first
and then having other people implement and use them. What would you lose
in being part of a more open-ended process with the users on board?
I think what is going to happen fairly soon (after the Orange Edition is
ballotted) is that I migrate my remaining specs out of
johnwcowan/r7rs-work and into pre-srfi repos, and then get out of the
SRFI business altogether. I will focus on WG2 duties, and will arrange
SRFIs into ballots based on availability rather than subject matter.
What does that mean for those pre-SRFIs -- will they be up for grabs for
other people to continue the work and submit as SRFIs?
A library collection would basically be the same thing, but putting
all libraries in a monorepo with collective ownership instead of
separate repo per library, each owned by one person.
The trouble with a monorepo is "once mono, always mono"
That would be exactly desirable for Scheme Live. We have to be able to
change not only modules, but module boundaries. Otherwise we're blinded
to important possibilities in the design space.
Current SRFI and pre-SRFI do not have a primary aim to produce one
cohesive language, and corresponsingly one repo per SRFI is a good idea.
Scheme Live should have as a main goal that the libraries make one
whole. [Insert obligatory joke about Buddhist at the hot dog stand.]
it is a pain in
the ass to extract a particular subtree into a SRFI repo,
Not sure I know this pain. Haven't found any fundamental problem with
it. There are better tools than `git filter-branch` now.
whereas if
each pre-SRFI is in its own repo it is easy to transfer it to SRFI space
and archive the pre-SRFI space. Ownership isn't really an issue:
everyone who is an owner of the pre-srfi org is also an owner of all the
individual repos, and there's no reason why everyone who wants to
participate can't be added as well. (Of course there will be some
participants who want nothing to do with GitHub.)
This is fine for SRFI, and if pre-SRFI is to be an exact mirror of SRFI,
then for that as well. The separate repos have thus far led to de facto
separate ownership by way of Conway's Law.
