johncowan

That raises a more general point. When you can't or don't have compile-time checks, removing run-time checks in production amounts to wearing your seat belt only when driving around a parking lot and then unbuckling when you get on the highway. It's very much the Wrong Thing.

there is no guarantee that [syscall stability] will last forever even in Linux given the latest attacks

That's true, but what of it? Linus won't last forever, Linux won't last forever, computers won't last forever, and Homo sapiens won't last forever. Everything needs maintenance sooner or later. "The Rockies may crumble / Gibraltar may crumble / They're only made of clay."

I remember the first time I heard of someone being fired for buying IBM, a thing that many people thought would never happen.

Not the case. Anyway, it's not about being quarrelsome, it's about having a different point of view. As for compromise, it's hard to compromise between strictness vs. laxness, for example.

Child A: I want the whole pie!

Child B: How about we split it 50/50?

Adult C: You two need to compromise. A gets 75%, B gets 25%.

(I am not implying that any particular persons are A, B, and C here.)

Not if it's so constraining to the implementer that you can't get any implementations. Nobody's paying us to do this stuff.

Damn, my emoji got eaten. See https://emojipedia.org/chair.

Sorry, not sorry. Here's one for you: .

We have had four models:

Committee consensus took us up through R5RS. There were about 30 members of the committee, though obviously some were more active than others. The problem with that was that we got no change except at the margins. Implementations were extended in random incompatible ways.

Then we had consensus of a small committee (5 members, later 4) for R6RS, followed by a community ratification vote. A lot of people thought the resulting standard was over-engineered, and I am quite sure that many people didn't understand all of it (I didn't for sure, especially macros and records.) Some implementers adopted it, others declared they never would.

For R7RS-small and the early stages of R7RS-large, we had the open SRFI process (anyone can propose, the community helps refine, the author decides when to freeze the result).

Now we have a (de facto) Sitzfleisch process: however stays in their seat and is still arguing the longest, wins. I eventually ran out of energy for this one.

Note that in all cases the text controls the meaning, not the author(s), and when the standard and an implementation collide, it is the implementation that is wrong. This is very nearly a sacred principle, as in C/C++ and various other multiple-implementation languages.

Alas, no. There are quite a few other things that are needed in what is now being called the Foundations in order for adding features to be done through libraries. Scheme, like other Lisps, is almost all "library" and very little "language", once you get past variables, constants, and function/macro calls. The only "language" feature added so far (in R7RS-small) is that previously a vector constant had to be quoted, whereas now it is self-evaluating: you used to have to say (vector-ref '#(a b c) 0), whereas now you can leave out the quote mark.

Racket is not an extension of Chez; Chez is an implementation language for Racket (it replaces most of the C code in earlier versions). See my comment above about implementation languages.

The main benefit of basing Racket on Chez instead of C was maintainability. A bit of performance and a few fairly unimportant features (like single floats) were lost.

Or more simply https://github.com/johnwcowan/r7rs-spec/tree/errata/rnrs, where you can get Every Scheme Standard Evar. It's unsurprising that there is no one place for R7RS-large, considering how inchoate it is.

The issue is that lots of languages don't make complex numbers part of what Lispers call the numeric tower, fully integrated into numeric operations, even if there is a complex library. Here's Guy Steele's 3-part smoke test for early Common Lisp implementations:

1. At the REPL, if you type `T` (true), and you get back `T`, the test passes.

2. Define factorial. Then type `(/ (factorial 100) (factorial 99))`. If you get back 100, the test passes.

3. Type `(atanh -2)`. If you get a complex number, the test passes. If you get the correct complex number [namely -0.5493061443340549+1.5707963267948966i] extra credit. Far too many non-Lisp languages return NaN or throw an exception.

For "precisely" read "correctly". Unless the implementation language is exposed to users of the implemented language, it doesn't matter what the implementation language is. gfortran is written in C and C++, but that does not mean Fortran programs are written in C or C++.

Which of course cannot be done portably except by drastic restrictions like "never add a number greater than MAXINT / 2 and never multiply a number greater than sqrt(MAXINT)".

Racket is far and away the most popular Scheme (and I reject the claim that it is not Scheme).

Very well said. A fourth group is people maintaining existing user code (including libraries), who also want backward compatibility.

Lisp is 65 years old and its future will be longer than its past! Another way to look at a fast-moving industry is that it's all hype and flutter with the occasional solid achievement.

If you really want to undo the Cambrian explosion, you will get Fortran and Lisp. A better SQL, Prolog, and something like Haskell might also be useful/necessary.

On the other hand, a theorem prover written by John McCarthy in 1958 was trivially adaptable to both Common Lisp and Scheme. Not too many languages get to make that claim.

If you mean me, I am definitely not a human sacrifice. I walked away because I had had enough.

I'm the ex(1) troglodyte in question. I don't use custom aliases, because I have had all editing tasks hardwired into my brain for decades, ever since I dropped Teco for ed and then ex. (Ed is the standard editor, but I'm willing to trade off a little standardosity for added convenience.) If the te command had been widely available, I might have stayed with it and not used ex, but that day has passed.

I do pipe stuff through various commands more or less constantly. I most often pipeline through awk, sed, sort, uniq, cat -n, etc. I have a back-burner project to write a meta-editor that works by pipelining and maintains a whole persistent undo-redo history.

Memory is a finite resource too, but would you force your students to run all their programs in 12K of memory, just because that was how much memory I had in the machine I learned to program on in 1972?

SQL is no/low-code compared to using a low-level database like BDB for a given level of power. And yet it's much simpler for most use cases.

By the same token, C is low-code compared to assembler, Python is low-code compared to C, and Steel Bank Common Lisp is low-code compared to Python.

There's a tradition of skullduggery-related names: Guile, Gambit, Gauche, Heist, Larceny (with variants Petit Larceny and Common Larceny), Racket, and Stalin (it optimizes your code -- brutally). "Chicken" is I believe related to an actual rubber chicken (which of course is also unreal).

Developed by Kent Dybvig, sold to Chez which did who-knows-what with it (hiring Dybvig as well) but never commercialized it directly, and then open-sourced by Cisco.

Chicken supports fx+ and flround as well, as do all R6RS and R7RS-large systems.

We usually write RnRS. If you're into Unicode or markup languages like TeX and HTML, you can write R⁴RS, R⁵RS, R⁶RS, R⁷RS, or generally RⁿRS.

And yes, I think that "The Revised Revised Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme" is pushing the joke rather too far, but R⁷RS is what name got consensus. It's modeled on "The {,Revised|Modified} Report on the Algorithmic Language Algol 60", where the usual abbreviations were R, RR, MR, but I like to write R⁰RA60, R¹A60, R²RA60 instead. Ditto with R⁰RA68, R¹A68 for the distinct language Algol 68. Finally, the incomplete report on the Scheme offshoot Kernel is R⁻¹RK.

A few notes:

1) R6RS isn't really all that "batteries included", though it has some really basic features like hash tables that weren't in R5RS (but were in most Schemes anyway). The emphasis was on portability and safety. All R6RS implementations, if they don't have bugs, behave the same as all the rest at least as far as the standard extends, and the standard defines pretty closely what arguments are accepted, what values are returned, and what exceptions are signaled (the last was controversial even within the closed R6RS committee).

What wasn't considered was interoperability with common practice in other Schemes. In pursuit of this, R7RS favors interoperability over portability: the standard is less constraining, which makes it easier to integrate with existing Schemes. So R6RS hashtables (things that can be hashted, eh?) are incompatible at the procedure name level and some of the semantics with almost everybody else's hash tables. R7RS-large made them as compatible as possible. (Granted, we took more time to think about it.) R7RS-large also favors big-enough-ism over minimalism within each library, though it won't have as many libraries as people from other languages might like.

2) The current plan for R7RS-large will provide many parts of R6RS (a little bit R7RS-ified in some cases), provided they are voted in by the R7RS-large working group.

3) The rename of PLT Scheme to Racket had nothing to do with RnRS. PLT supported R6RS before and supports it R6RS today, though its use is not particularly encouraged by the Racketeers, who want you to use their own main dialect of Scheme, also called Racket. The change had more to do with PLT's multilingual capabilities: it supports many dialects of Scheme plus completely non-Scheme languages like Python and Algol 60, and it would be straightforward, if tedious, to provide Fortran, Cobol, and even C. In addition, PLT had no real link with the various university programming-language theory groups any more.

On participating in the Working Group:

Any Schemer can join the Working Group at any time: subscribe to scheme-reports-wg2@googlegroups.com and listen for CFVs. (If you have never voted before on anything Scheme-related, send a message after you subscribe giving your name, a little bit about yourself, and a bit more about your interest in Scheme. This is primarily to discourage sockpuppets.) There are long spells of inactivity followed by intense discussion when a new ballot comes up. All discussions and votes are public. Behind-the-scenes work is also done in public using the SRFI process at srfi.schemers.org, which produces specs and sample

In fact, your strategy can forward your goals with no causal connection to what you want to change, either by sheer luck, or because your rhetoric inspires people to do the Right Thing by some completely different means.

But I agree, of course, that these are not to be counted on.

You might want to look at MicroXML <https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.h...> then. No XML declaration, no DTDs, no PIs, no CDATA sections, no cruft.