On 13/03/2022, elf <e...@ephemeral.net
> Has anyone realised yet that the whole bent of the R7-large, R7-medium,
> etc etc etc is not going to do what its supposed aims are?
> The goal of these projects is to create some kind of standard library to
> allow interoperability.
> It won't work.
Maybe that's why John made his proposal. A small, self-consistant set
of libraries that use only R7RS Small will avoid all problems. So I
would say many SRFIs won't work because they depend on many features
not in Small. Some of them are not consistant with each other.
> All this will do is increase the size of the base with which people are
> working. As soon as someone wants to do something interesting outside of
> this, they will still (likely) be building on implementation-specific
Your definition of "interesting" may be the problem. I prefer *useful*
as the primary criterion. It has no such problem. Useful libraries
written in R7RS Small. Build a set of libraries consistant with each
other. That could be the "Foundation" set. Then build another set
upon that and Small.
For years I felt that was how WG2 should be doing R7RS Large. So I can
sympathise with many of the arguments and points made recently.
However, as I've begun using the Large libraries, and also importantly
*integrating* those libraries into one modestly consistant set based
on the reference implementations for the corresponding SRFIs, I've
found various self-consistancy issues.
I'm using a (scheme small) library to import and re-export
*everything* in the Small library set. No conflicts. While my (scheme
large) library reveals many conflicts. I resolved all of them by
modifying the the implementation code. E.g. ensuring that (scheme
hash-table) and (scheme comparator) use the same two string hashing
procedures. This is a trivial change and AFAICT breaks nothing.
So I doubt that any path forward that ignores self-consistancy at this
basic level - can you import sets of the libraries without getting
conficting definitions? - *then* you will at least have some cleanup
John's proposal to restructure WG2 includes a cleanup sub-committee,
which I support. WG2 will need something like that or else, as you
neither Medium nor Large "will work" i.e. integrate without serious conflicts.
> Further, the cost of this is locking the language as a whole into
> today's thoughts for libraries.
I believe its way too early to talk about locking anything, except the
Small set. Changes there will risk breaking existing code. See John's
point about closed-source code. We may not see that code - its not
available to us - but it still exists. An absence of evidence is not
proof of absence. Small has been published, implementated. There's
plenty of proof of *that*. We should assume that some programmers are
using even if they don't speak up here.
BTW, I'm one of those users. I *am* speaking up. Please don't break my
code. Please don't break the code of others who are not (yet) speaking
up. They'll be real unhappy if and when they discover WG2 didn't
consider the value of their code. It won't necessarily mean they'll
abandon R7RS or their codebase. It may already be far too late to do
I recently mentioned the issues in the C world in another post. There
are some unhappy C programmers out there. They seem to feel betrayed,
but I can't speak for them. I can only observe that they exist and C11
is a problem for them.
> I consider this to be a massive mistake, not to mention entirely
> un-schemey (and unseemly, given the current level of discourse).
I consider creating a schism to be a massive mistake. Please beware.
The Scheme community really doesn't need that.
> I propose the following means of solving the actual problem motivating
> all of these projects, in order:
> 1) A very clean means of defining modules/libraries, including
> dependencies, interactions, download location, update characteristics, etc.
We already have most, if not all, of that. Not everyone in the Scheme
community accepts such things. Not everyone in any language community
seems to accept such things. However, I can see some degree of success
in this area in the Haskell community, so I believe that attempting
your proposal has some merit.
> 2) A centralised CPAN/CTAN/hex/whatever node.js is using today/pip type
> repository. This will enable modules to actually work interoperably
> everywhere, given 1), and will lead the implementations to
> adopt/modularise any implementation-specific features
It *may* do that. It could be argued that the SRFI repo already does
this, but I noted above, there are some unfortunate inconsistancies.
So while I believe your second proposal has some merit, I must ask:
what's different now? If this hasn't this already been done, how will
happend - and succeed - in the future?
Well, I suggest the existing work and progress of WG2 will naturally
support your proposal, but is independant of anything WG2 may do. You
don't need anything from WG2 to make it happen. Instead you need
widespread support and involvement of the Scheme community. I doubt
very much WG2 can help directly with that beyond giving that community
a language it can accept and use. Everything in your proposal depends
on WG's success.
> 3) Networking - the implementations will need something working, and if
> this is unified, it makes the above easier, but it can actually be put
> off until the earlier ones are complete, as most implementations already
> have some kind of network system in place. The biggest question with
> this is whether network sockets are ports, and if so, how to modify the
> ports abstraction to handle two-way controlled IO with OOB data.
Please see my earlier points about building sets on libraries. Please
also see John Cowan's proposal for restructuring WG2. Your third
proposal fits into John's proposal. One of his suggest sub-committees
could tackle this. Perhaps a networking sub-sub-committee?
A even simpler approach: try writing a networking SRFI. Build on
existing work and let the Scheme community judge its merit. Then WG2
will have something to work with. I've believed for years - decades -
that this may be how the Scheme community succeeds. When the practical
requirements of the community are met, we see this reflected in the
SRFIs being supported and used. We can actually *see* this in the code
that is available, both in the SRFI repo and in implementations
supporting those SRFIs.
> 4) FFI - this can REALLY be put off, but just as a note, this should be
> in the form of per-language interfaces, that is, c->scheme, scheme->c,
> c++->scheme, scheme->c++, scheme->java, java->scheme, etc. Trying to
> unify this into a single massive FFI is doomed to conceptual and actual
I'm going to assume you're aware of SRFI 198. (If not, you should be
now I've mentioned it.) What does this SRFI fail to do that your
proposal will address?
> I submit that we should start with R5RS, the last universally agreed
> upon standard, layer on libraries and networking, with reference to a
> centralised library repo, and go from there. I further submit that the
> cost of trying to maintain perfect compatilibity with R7 and
> (especially) R6 is far lower than the cost of rewriting the code to fit
> a new system.
R5RS was not universally agreed upon. It was however widely supported.
That's not the same thing. Since then R6RS has also become widely
supported. R7RS Small is in the process of becoming widely supported.
Perfect compatilibity is an impossible goal. Many R5RS systems weren't
even compatilible with each other. Many of them still exist and their
incompatitiblities may still exist. I don't know. I write very R5RS
code today. I test it on very few systems. However, I see a lot of
R5RS code still being used and supported. See the SRFI repo for many
Also see the SRFI repo for examples of R6RS and R7RS code. See the
three hash table SRFIs and how the SRFI 125 and SRFI 126 reference
implementations build on an earlier hash table SRFI. I think they show
how all three can co-exist in an pure R7RS system. R5RS and R6RS
systems maybe have higher requirements. See real systems for examples.
As I've said here before, I believe Chibi and Larcent, perhaps even
Guile, are existance proofs that there is no problem here.
> > The role of the SRFI process in this cannot be underestimated, both as a
> means of discussing the above interfaces, and for creating standard
> libraries to be added to the repo.
> That said, obviously not everything
> in the repo will be an SRFI, nor is it necessary to do so - but there
> are certain types of more standardised functionality or (more
> importantly) base-level language modifications that can only be solved
> by the excellent work done through the SRFIs.
See my earlier points.
> The floor is now open to flames and rebuttals. Thank you. :)
No flames here. Maybe some rebuttals. Definitely many questions.
> PS - As a further note, the level of discourse between people who have
> not actually written implementations, are not responsible for
> implementations, have very little skin in the game in terms of
> production level code or SRFIs, etc should perhaps be a little less ...
> rigid towards those with decades of experience working in and with
> Scheme at all levels. I am not singling out any names, but the whole
> reason I am proposing this before writing it up as SRFIs myself is to
> try to cut the gordian knot that has been created recently in the
> discourse, with threats backed up by nothing and general unpleasantness.
I hope none of that "unpleasantness" you see has come from me,
I personally see little that I find unpleasant and can recall no
threats. Perhaps some disagreeable posts, but hardly unpleasant or
threatening - with one small exception, which was offensive, and I
immediately addressed that a few days ago.
So I appreciate your postscript. I merely point out that you may not
see everyone's code. I personally value the code written by *users* of
a language. I'm not comparing that value with the code of
implementations. I'm simply saying we won't see every Scheme
implementation. We might not even see the code compiled by every
Scheme. However, some of us can recall real world code created by such
systems and seen people pay for it and use it. I think that also has