> Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery
I've been writing a picolisp-like lisp interpreter[1] and I have really noticed this too. I added a length built-in just because recursion wasn't working properly, but if I had continued without the important functionality for too long, I would have needed to implement many more functions (and the lisp still would be missing important things).
Was R7RS-large ever ratified? It doesn't look so to me, but it's been so long that I'm not sure I'm looking in the right places.
R7RS-large is a work in progress, and will not have a single "ratification" event. The work has been divided into editions named after colors, which are cumulative. So far the contents of the Red Edition and the Tangerine Edition have been voted on (anyone interested can vote) and are established; the Orange Edition is currently in preparation.
We use the SRFI process to develop specific components of an edition, which means that all components already have implementations before they are voted on, usually portable ones. See r7rs.org for details.
Hey John!
I'm curious; is there any possibility that Scheme will eventually abandon call/cc in favour of delimited continuations?
R7RS-large is Racket ;).
(This is a joke, do not take this seriously.)
Yes, it was ratified:
https://en.wikipedia.org/wiki/Scheme_(programming_language)#...
That page says R7RS-small was ratified but not R7RS-large, and http://www.scheme-reports.org/ says the same
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.
[The] Scheme Steering Committee decided in August 2009 to divide the standard into two separate but compatible languages — a “small” language, suitable for educators, researchers, and users of embedded languages, focused on R5RS compatibility, and a “large” language focused on the practical needs of mainstream software development, intended to become a replacement for R6RS. The present report describes the “small” language of that effort: therefore it cannot be considered in isolation as the successor to R6 RS.