I'm satisfied with a relatively small language that can be used to build a larger language. My for own uses, this language is a subset of R7RS Small because I don't need eval. I can write a self-hosting compiler using that language. I can, and I do, frequently use it to extend the language. For example, extending define-optionals* and let-optionals* to support the full Shivers syntax. I didn't need syntax-case to do that, but I can see how that would make it easier. Also, better error messages could be given for malformed expressions.
So I'm ok with the Small dialect plus various SRFIs. If the Large dialect does nothing more than standardise some names for those libraries (e.g. (scheme list) for SRFI 1), then I can support that. I don't feel a need to change the semantics of procedures like vector-ref because I can use assume (SRFI 145) to check that an index is in range. I learned to write "defensive" code this way when I was a teenager, in the early 1980s. I also learned how to generate indexes that won't ever go out of range. I think of this as basic "potty training" for programmers. Nothing in the Scheme language has ever made this hard to do. We should be very careful when considering any change to a language that may break existing code. Various dialects have done this, e.g. Racket making cons create immutable pairs. This may be solved by use of Racket's module language, but it places an undesirable burden on anyone trying to use code written for the language in Scheme reports. R6RS also created a few problems, but none so great as Racket. R7RS also creates a few problems, like renaming a few procedures. Adding features is much safer than changing or removing popular features. While I would have prefered it if (scheme eval) etc were in the Large rather than the Small dialect, I believe it is too late to change that. This will be a minor inconvenience. Nobody appears to be complaining about eval. It's easy to write an R7RS compiler that doesn't include eval. Consider a self-hosting Scheme compiler that compiles whole programs into C. Does this require eval? It could support a useful subset of the language without it. A useful subset of eval can be written in Scheme for programs where that's needed. It won't compile into C, but a useful subset of eval may not need to. E.g. when a program only uses eval to map symbols to procedures defined in the language or the program itself. One obvious application for this would be a compiler that performs constant folding. There's value in a moment of reflection, as we're doing here. Overall I'm happy with the progress made by WG2 so far. I see a lot more work yet to be done, liking the final cleaning up and documenting. Obviously there are still issues with define-record-type. There have been many proposals for syntax extensions and a procedural layer, but no obvious consensus on what should go into R7RS Large. The fundamental questions, like can it be done, and done efficiently, were as you say, settled years ago. On Sat, 18 Oct 2025 at 21:53, Daphne Preston-Kendal <[email protected]> wrote: > > On 18 Oct 2025, at 21:44, Dr. Arne Babenhauserheide <[email protected]> wrote: > > > Daphne Preston-Kendal <[email protected]> writes: > >> Even Guile has this problem, because it’s still culturally normal > >> among users of that implementation to use its own define-module > >> declaration instead of the standard R6RS or R7RS library or > >> define-library > > > > Would it be possible to have a utility that transforms these files to > > standard scheme? > > Maybe! There are multiple levels on which such a script would ideally need to > operate: lexical syntax, library names, and identifiers. There is also a lot > of Guile code which is *nearly* RnRS-compliant, except it uses keyword > arguments or some other relatively small feature which could be replaced, but > would certainly require manual work for that. > > >> shy of compromise; the uncompromising pursuit of perfection, even > >> though perfection is a quality nobody will ever agree on, may be why > >> we have struggled so much to move onwards while other languages have > >> not. > > > > On the other hand, there is a lot that Scheme reports got right. > > > > The past seven years working professionally with Java and (later) > > Javascript I repeatedly hit on problems that wouldn’t have existed with > > Scheme. > > > > So I think that pursuit of perfection has merit. > > > > On yet another hand: the writers of the reports got things right I would > > have gotten wrong. So I don’t know how much impact my experience should > > have. > > > > How were Scheme reports able to get so many things right? > > By being written by very smart people. (I do not flatter myself here; I have > remarked before how daunting it is to follow in their footsteps.) > > Also, by being very slow. But R6RS dared to go quicker, and managed to avoid > disastrous technical mistakes in large part. Parts of it were not to some > Schemers’ taste, but I doubt anyone would say that any part of R6RS is so bad > as to be unusable for writing programs. > > As an example of what I mean, read the rationale to SRFI 99 to learn how > records were debated for twenty years before the R6RS finally put a record > system in the report; it was even 12 years from the first rrrs-authors post > about records before we got SRFI 9 as quasi-standard, before R6RS. The > authors before R5RS didn’t want to put anything less than perfect into the > report; but they couldn’t all agree on what was perfect, so two further > revisions of the report passed before anything happened at all. In reality, > the debate in those days was over two things: automatic name generation and > whether a procedural layer could be as efficient as a syntactic layer. > Automatic name generation is a Marmite issue (you love it or you hate it, and > those who claim to hate it often, but not always, soften their views when > they eat it thinly spread with butter over a hot, toasted codebase instead of > a whole spoonful at once in isolation), and a bikeshed one at that. Even if > procedural layers were thought to be more inefficient than syntactic ones, it > is absurd that that issue held up even a syntactic layer alone (with an > unspecified procedural layer implied to be underneath, like syntax-rules in > R5RS). Doubly absurd when one considers that a syntactic layer + eval = a > procedural layer, if anyone wanted a portable one of those before it got > standardized. That Dybvig himself co-wrote the paper demonstrating procedural > records are just as efficient as syntactic layers, just five years after R6RS > bent over backwards to discourage mixing of the syntactic layer with the > procedural layer, is the perfect tragicomic ending. > > But that is the kind of inertia that comes when you only accept things when > everyone agrees they’re perfect. Sometimes resisting compromise is justified: > I am glad we managed to avoid putting a procedural macro system into > R7RS-large which would not have allowed unhygienic macros to compose > correctly with hygienic macros. In that case, we had the weight of history on > our side (not only R6RS but the low-level system of the R4RS appendix). I > won’t win every debate, though, and that’s okay by me. > > Being open to compromise also does not mean being open to accepting untested > ideas. The Scheme reports are well-designed because so many things in them > have been thoroughly tested *before* getting standardized. The outgoing > steering committee asked us to limit ourselves to features with support from > at least 3 Scheme implementations – I think this was a good idea, although it > hasn’t totally reined in our desire to innovate. Sometimes innovating in a > standard is okay though: Haskell wouldn’t have type classes if they hadn’t > dared to put them in the 1.0 report with comparatively little testing. > Everything in moderation. > > > Daphne >
