Is Scheme going to become a Common Lisp wannabe with the release of R7RS-large? It will be starting at a disadvantage relative to Common Lisp. This would merely divide the Scheme community.
It will not be possible for R7RS-large to compete with Common Lisp in terms of real-world software deployments. If history is any indication, R7RS-large will immediately fracture into multiple implementations that are incompatible with each other, just like what happened to all the other RnRS implementations. When will Scheme programmers rise up to demand the portability of their Scheme code?
If R7RS comes with more useful, modern utilities (POSIX, networking, multithreading, perhaps FFI, etc.) I think it will have an advantage of being better designed and cleaner.
R7RS-large is supposed to be larger than Common Lisp.
The relative sizes of the languages are approximately thus: R4RS < R5RS < R7RS-small < R6RS < Common Lisp < R7RS-large.
Is R7RS-large some extensions to R7RS-small or is it a completely different thing? Will a portable R7RS-small program work flawlessly on conforming R7RS-large implementation?
>>5
Yes, R7RS-large is the superset of -small.
Yes, the -small subset standard is supposed to be a part of the -large standard.
>>6
How can we be sure of that when R7RS-large has yet to be ratified? R7RS-large is not even 20% complete!
>>5
From what I see, R7RS-large adds additional standard libraries through the R7RS-small library system. So far, the ratified parts of R7RS-large are SRFIs.
>>7
Yes, it is true that R7RS-large is within the ratification process. This means that there is the potential within the process for -large to change its details such that the definition of -small does not become a proper subset of -large. My crystal ball prophesy of the final R7RS-large standard is that the small standard is going to be a proper standard of the large standard.
The reasoning for this is based on the context of why there are large and small standards for the same language: it will be a practical language for the largest amount of software developers. There are real world applications in which only a "basic" amount of programming logic needed to fulfill the job; the small standard is good for these kinds of software applications. In real world practice, it has been shown that the different Scheme implementations re-implement functionality between the implementations that are not currently part of the standard. This is the motivation of why there are Scheme Requests for Implementation (SFRIs). The large standard is good for the wider world of applications that's practically used in the wide world: the functionality in the large standard is because we know for a fact that the specific function pieces are widely used.
So it the case that the large standard is an extension (a superset) of the small standard; I couldn't fathom a practical reason to justify designing the large standard so that isn't the case. Despite knowing nobody within the Scheme committee, I'm very confident that the ratified R7RS-large standard will be a proper superset of the R7RS-small standard; thus all conforming -small implementations will be compatible to all conforming -large implementations.
It took about 10 years to complete the Common Lisp standard. How long is R7RS-large going to take? At the rate it is currently going ... 30 years?
When will Scheme programmers rise up to demand the portability of their Scheme code?
I would be interested in this. Do any of you know anything about creating test suites for standard compliance? I think that would be a good first step, but I have a hard time finding anything about it on the interwebs.
When will Scheme programmers rise up to demand the portability of their Scheme code?
A major improvement of R7RS-small over R5RS is that R7RS-small standardized the library system, and has cond-expand. I believe that the addition of these features made it easy to write portable and standard Scheme code.
>>11
I think the bigger issue is relying on unspecified behavior, or implementation specific extensions. Also implementation details are generally undefined, so performance will always be a bit difficult to maintain portably. A simple example of this is that strings can be implemented immutably, meaning it's best to use ports to build strings.
What may be interesting, and not too outlandish is to have a sort of (non-optimizing) minimal sane implementation with similar treatment for SRFI. The main difficulty with this if I remember correctly would be evaluation order, character set, and numeric tower.
>>13
In R6RS I believe the only major issue would be the evaluation order of operands, binding forms, and iterators when side-effects are involved. For the sake of portability the compiler would signal an error when side-effects are used in these forms. One would then tend to use many begin, or let* forms, potentially with new special forms such as Shivers' loop or Clojure style "threading" macros to relieve some of the inconvenience of this. How could you conveniently handle IO though, and what about when modifying a global is actually useful to do in a subroutine? I'm certain FP people would have some good ideas on this topic...
>>14
What is "Shivers' loop"? Is it Common Lisp's loop macro?
>>15
It's a Common Lisp style loop macro but which takes scoping seriously, probably the best of its kind: http://www.ccs.neu.edu/home/shivers/papers/loop.pdf
There was a talk about R7RS-large at the Scheme Workshop 2021, but I can't find a recording of it online, did anyone here attend it?
https://icfp21.sigplan.org/details/scheme-2021-papers/6/Large-Scheme-Tis-Seven-Years-Since-Invited-Talk-
At any rate we have an excellent idea of what proposals remain to be voted on: 26 SRFIs voted in, 85 SRFIs (and parts of R6RS) waiting to be voted on, and 65 pre-SRFI specs, only a few of which have implementations.
oof
>>17
It looks like R7RS-large is going to take half a century to complete. By the time the standard is published, it had better be the most magnificent programming language to have ever existed.
>>18
For me that's not important that the language is in development for a long time. I am able to start my project with R7RS-small and develop it to maturity together with all the currently approved SRFI for R7RS-large. When the time comes, I am confident that it would be "not hard" to migrate any existing code that doesn't make use of newly approved SRFI into the standard. I say this in the same sense that it is "not hard" to translate a C standard project into a comparable C++ project.
(POSIX, networking, multithreading, perhaps FFI, etc.)
This is exactly what I want out of R7RS-large to be able to write portable libraries, but it looks like large is only a subset of SRFIs right now.
https://practical-scheme.net/gauche/man/gauche-refe/R7RS-large.html#R7RS-large