1. 22

Looks like most of R7RS is supported.


  2. 6

    It took me a while to notice that the GNU project has two Scheme implementations, MIT/GNU Scheme and Guile. Is there any non-historical reason for it? Is one faster while the other (presumably Guile) has a better C-API or is internally more extensible?

    1. 6

      I don’t know why MIT Scheme was made official GNU (probably because Stallman studied at MIT and maybe even worked in the implementation), but as far as I know the idea behind Guile was that it was intended as the official scripting and extension language for the GNU system (GUILE stands for “GNU Ubiquitous Intelligent Language for Extensions”).

      MIT Scheme used to be much more heavyweight full-fledged Scheme implementation. Nowadays Guile has grown to be quite large (and there are lots of packages for it) so that it can be used separately for complete programs too, so the distinction is blurred.

      1. 3

        Allegedly, MIT Scheme was around before the FSF or the GPL existed and was also licensed under a copyleft license. If true, it would be a good bet that MIT Scheme inspired the GPL and was subsequently adopted by the FSF.

        1. 3

          The changelog contains git commits (probably converted from some other VCS) that date back to 1986. Kind of funny to see :)

      2. 2

        I believe you’re right. MIT Scheme is a real-life native code compiler, and correspondingly has better performance; Guile is designed for embedding and extension, and has a better C API.

        1. 1

          GNU has a third Scheme implementation that targets the JVM. I was reminded to post this because I saw that GNU also has two Common Lisp implementations: GNU Common Lisp and CLISP.

        2. 2

          Interesting, a couple of years ago I remember reading (official page maybe) there were no plans to support anything beyond R5RS. EDIT: My mistake, here they said support for R6RS will never happen which is a completely different statement. For the experienced schemers, what is the controversy around R6RS?

          1. 2

            For the experienced schemers, what is the controversy around R6RS?

            It was overreaching, too large, invented new things for stuff that already had established alternatives, included some controversial changes like the syntax-case macro system (which is a beast to implement and is incompatible with syntactic closures or explicit/implicit renaming macros). This standard was also the first to not require a supermajority. Basically, it felt like the standard was hijacked by people with a certain agenda. Historically, Scheme has been very broad, allowing a diverse set of implementations, from very simple toy implementations to systems for education, systems for productivity use, embedded use and everything in between.

            Read some of the ratification comments if you want to laugh (or cry).

            1. 1

              Thank you for this, I will certainly have a good read on the link you provided. Does R7RS suffer from the same issues you pointed out?

              1. 4

                The R7RS steering committee realised that R6RS created a bit of a schism in the community, so they divided up the spec into two parts: “small” and “large”. The small standard is finished by now and is basically R5RS plus a relatively simple module system (yay!), exceptions (yay!), bytevectors and a few other odds and ends that provide a decent base language.

                It’s not without its flaws but overall I like the standard they’ve hammered out.

                The “large” part is a sprawling set of libraries that will give Common Lisp a run for its money when it’s finished. It will have everything, the kitchen sink and more. The spec is being developed via the SRFI process, and Scheme implementations can choose which parts they want to implement so there’s unlikely to be a lot of controversy. Personally, I don’t have the mental bandwidth to keep up with all the stuff they’ve been putting out, so it’s a bit of a parallel universe to me.

                1. 1

                  The world needs both, personally, I’d like to see R7RS-large layered on top of R7RS-small. By doing so, any -small could be transformed into -large and would show that the base special forms and abstractions are good enough.

                  It would be as if rt.jar could be taken to any JVM.

                  1. 2

                    Many, perhaps even most, libraries in R7RS-large are implementable on top of R7RS-small (though you might not want to, for performance reasons). This is nice as there’s usually a reference implementation available. If R7RS-small offers all you need, that means you won’t need to make multiple reference implementations specific to various Scheme systems.

                    But requiring R7RS-large to be implementable on top of R7RS-small in the general case is a bad idea and sometimes even impossible, simply for the fact that R7RS-large will include things that require special runtime or compiler support. For example, suppose an FFI for C (or Java, or any other lower-level system) was standardized. There’s simply no way a base language could support that.

                    And given the nature of R7RS-large, there will be libraries that smaller Schemes are simply uninterested in implementing (for example the continuation-marks SRFI). Even though this could be seen as a “lower level” library which could go into the base language so that other SRFIs can build on top of it, it does not belong in R7RS-small.

                  2. 1

                    Thanks again for your response. Now, I have a better understanding to what’s going on. Awesome work you guys are doing with chicken, by the way.

                2. 1

                  hey wanted to chime in and thank you for the comments, I’ve an interest in the process as a whole but not the bandwidth right now, and the illumination is appreciated.