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.
I wouldn't really characterize it that way. You (ideally) shouldn't be hitting code paths in production that you didn't ever hit in testing.
But, in any case, if you are fine with the slight performance hit (though many C/C++ projects are not), you can always just keep assertions enabled in production.
> 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."
What you say is true, but you've inserted an inaccurate context with the quote.
There is no guarantee that _direct access to system calls_ will last forever...
Stability in the syscall API exists because Linux is a kernel that supports multiple distributions. Not because random applications could call it. The latter is an emergent feature, but not one that distribution maintainers will necessarily respect. POSIX only guarantees access to functions in libc that can perform these calls. As mentioned elsewhere in this thread, there are specific reasons why future direct access to system calls in user code could be restricted. Whether they will or not comes down to how distribution maintainers decide to deal with syscall related ROP gadgets.
I think that ship has sailed in the 90s. From the 80s to the 90s IBM dropped like 50% of the people that worked there and lots of companies were moving away from mainframes in droves. I'm sure some people got fired for sticking to mainframes to long and wasting money. And likely some companies went bust in the late 90s for having a IT infrastructure based on IBM Mainframes.
That's mostly speculation but it seems like it has to be true.
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.)
Of course not, but knowing that the program should never continue executing in an erroneous state is for me a pretty nice-to-have. Scheme enforces correctness and safety in many places and I think that one in particular is important enough to warrant being opt-out rather than opt-in.
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.
