Ticket 519: Toy Schemes shouldn't be the measure of what belongs in the standard

Aaron Hsu writes:

Unfortunately, there seems to be a great deal of sentiment that drives standardization in Scheme that the standards should conform and coddle the least common denominator. All too often I hear, “That’s too much work to implement in a toy scheme,” as a good reason for not having a feature. Especially, for not having features that remove the need for having a handful of other features. We should be focused on making an useful, expressive language, rather than trying to bend over backwards to make the language easy to implement. If we really wanted to follow that line of reasoning, then we would not be using closures or any of the other language features that Scheme has introduced. Indeed, Scheme has often led the programming community in introducing features that others thought too hard to implement well. Well, Schemers then implemented them well, and the result was a language that was powerful and elegant and usable. The standard should be taking the intersection of high-quality, industrial strength implementations, not the intersection of very toy scheme ever written. That is not to say that toy schemes are not vitally important, but we need to get over this love of saying “This is a fully compliant Scheme!” for every toy scheme ever written. It’s perfectly okay for us to not expect toy schemes to be fully standards compliant. Research Schemes, too, need not be fully standards compliant. If we continue to hold on to the idea that our Scheme implementations should be easy to implement above more elegant programming constructs, then we are doomed. Scheme standards such as R5RS have, in the past, served as little else but the measure by which a toy scheme could enter into the fold, rather than serving as the useful programming standard by which real work was done.