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
