The Scheme language's small size isn't necessarily a strength
So I was reading through part of the EmacsWiki and in the article on the Scheme programming language there are references to this ancient online debate from August of the year 2000 at the comp.lang.lisp Usenet group started by the late Erik Naggum, who was apparently a somewhat opinionated and inflammatory individual, who brought up the Scheme/Common Lisp debate on comment thread about someone being confused about how the CASE clause works.
The Scheme language standard at the time was R5RS, Naggum's argument is a common refrain from Scheme fans such as myself, and he was arguing with Kent Pitman ( @kentpitman ) who was one of the sub-committee chairs of the Common Lisp X3J13 standardization process, and is the editor and maintainer of the Common Lisp HyperSpec, an online form of the Common Lisp specification. Kent Pittman's reply I thought was very well-reasoned, and worth re-posting here (quote):
I just absolutely don't believe the Scheme standard is fairly cited as a model of a "better" standard. It is enormously vague on numerous matters of consequence. It omits really essential functionality that would be needed to write any seriously portable programs. It was stagnant for years on quibbles over some of the silliest syntax details. In my opinion, it's a toy language. There are real commercial Scheme implementations, but only by the sheer will of those implementers who've gone beyond the so-called standard and written in the things that the standard ought to have said in order to make the language finally useful. It achieves its "prettiness" and its "smallness" on the back of just plain leaving stuff out where it would appear to "clutter", and whatever you think of CL, I personally reject any claim that the Scheme is a model of improvement.
(end quote)
I wouldn't go so far as to call Scheme a "toy language" because the parts of the standard that are well-defined are solid and very useful. But yes, it seems the only useful implementations do solve these problems not addressed by the standard in completely different ways that makes it very difficult to write a Scheme program on one implementation that runs on another. Try to write one program that runs on MIT Scheme, Guile, Chez, Racket, Bigloo, Cyclone, Stklos, and Gambit. Try to even compute what set of SRFI (language extensions) are common to all of them. Most Scheme programmers have to pick just one implementation and stick to it without much hope of ever porting their programs to other implementations. It is possible to do it, easier than porting a program from Python to C++, but still not at all as easy as running the same Common Lisp program on SBCL, ECL, ABCL, or Franz.
So I do agree with @kentpitman that there are some pretty important details left up to the implementers simply because none of them could agree on what to do and punted the issue rather than resolve it. Later (after the aforementioned Usenet debate) R6RS would try to solve these issues, but that standard was mostly rejected by the larger part of the Scheme community due to a lack of consensus. Much of that work lives on in the SRFIs, while Chez Scheme (R. Kent Dybvig) seems to be sticking to R6RS and is one of the most well-respected Scheme implementations, and a kind of flagship of that standard.
I still have hope for R7RS-large though, which might end up being even larger than X3J13 when all is said and done. Unfortunately, recently John Cowan, chair of the R7RS-large standardization committee threw his hands up in resignation a few months ago after almost 10 years of trying to hammer-out consensus over details of the new R7RS-large standard. Daphne Preston Kendal ( @dpk ) has taken over and is fully capable of continuing the work.
It might be interesting if some Schemers could get together and write a new fully R7RS-compliant Scheme-to-Scheme compiler in R7RS-small Scheme, with all of the COND-EXPAND expressions in place to run on all of the major R7RS-compatible Scheme implementations. This compiler would simply translate its input into code that the host Scheme compiler can compile, deferring low-level implementation details to the host. The compiler should be one massive file that you could just load into any Scheme compiler and it just works. Then this compiler maybe, just maybe could become The Scheme Standard. A good starting point would be the work of Marc Nieper-Wißkirchen who has written Rapid Scheme which compiles R7RS Scheme to another host Scheme, but it only supports Chibi and Larceny as the hosts.
According to the Ecraven's Scheme benchmarks, MIT/GNU Scheme is the 6th fastest major Scheme implementation (Guile is the 7th), and I have found it has several incredibly nice, ergonomic features unique to it. It even has its own text editor built-in (Edwin) which is a clone of Emacs 18, so it is quite archaic, but still gets the job done when you need to debug your Scheme programs. MIT/GNU Scheme is also quite minimal, which is good, but it unfortunately does not have as big a package ecosystem as Guile, Racket, or Chez.
I wrote a library for Functional Lenses in Guile Scheme, and I was going out of my way to stick to the R7RS standard, and to only use SRFIs (official Scheme language extensions), and not use absolutely any feature specific to Guile or the Guile namespaces. Then I tried to port my library to MIT/GNU Scheme, putting in the necessary "cond-expand" expressions... and it didn't work at all, even though MIT/GNU Scheme is in fact R7RS compliant. To be fair, I could probably make it work with a little more effort, for example, I have not yet learned how to use the debugger, and without the debugger, MIT/GNU Scheme tells you nothing when an error occurs.
I am just a little disappointed with how much effort it takes to make a R7RS compliant Scheme program work across just two different implementations. I hope I might have more luck building it with Larceny, Gambit, Racket/CS, Loko, and STklos. If I ever get my Lens library to work across all of the R7RS compatible implementations listed at docs.scheme.org, I'll report on what steps I had to take in order to make my R7RS Scheme code truly portable.
In other schemery news, it appears that the Scheme Steering Committee is alive and kicking. They have accepted John Cowan's resignation from #Scheme Standards #R7RS Working Group 2, and appointed Daphne Preston-Kendal as the new Chair of Working Group 2.
Great news overall - we might even get a R7RS-Large Report before Extinction.
I think something the scheme community could learn from Haskell is to lean-in on it's prestige. I see so many people post about how they were never able to figure out how to use scheme in any practical way, and most schemers I've spoke to said it took them about a year to get really compfortable. But I think the #scheme community has traditionally advertised it as "so easy, you can learn it in an afternoon!", and so people, often times already coming from some other #lisp like #clojure, expect to be able to just pick it up, and when they fail to they think the language is lacking. But nobody comes to #Haskell with such expectations, and the Haskell community never advertised it as super easy and quick to learn. In my experience, Haskell has always been sold as "takes time to learn, but is worth it".
@ramin_hal9001 the thing is, I would say this is starting to change with r6 and #r7rs implementations, and #akku does a pretty job of working out the compatibility between different implementations (but the guix package needs some fixing... on my TODOs).
but I agree about the pressure to pick the right one, it drove me mad, but I also think that the idea that getting used to multiple schemes is impossible, and it should even be encouraged to work with a few of them, because once you've navigated a couple, they're all kind of the same at root. but I think people should stick to one for their first year.
it's primarily just the #r5rs implementations that differ wildly. I think theres this mythology that r5rs was this legendary, impeccable standard, and that the process went astray after that, but the truth is that #r6rs really was a massive improvement, and r7rs-large will be something like r6rs (creating an r7rs compatability later for r6rs schemes is a matter of defining a module and a few identifier-syntax macros). problems with post-r5rs are primarily social, rather than technical imo.
Binding of functions with optional return values is an obvious hack. It’s commonly done in #Icon, for example, by having a procedure in a chain of computations FAIL rather than RETURN.
The list monad is widely used by authors to produce a list of some Pythagorean triples. This is so easily done with just a single tail recursive function as to make the monad version pathetic. :)
Question for anyone familiar with #Scheme programming, and in particular #Guile (@wingo): how hard would it be to port GOOPS to other Scheme implementations like #Chez, #Gauche, Gerbil, or Chicken? I know that other Scheme implementations provide their own #OOP systems (e.g. Chicken COOPS), but what if I want my library written in Guile to be more portable, could I still use GOOPS and try to move the code over to some other platform?
Or has this already been done? Is there a portable GOOPS, akin to a large Scheme library such as SLIB?
Also I realized that using the transparency channel meant I had no need for gamma correction! But it then did require constructing an image from parts. That’s what made it more fun, though.