Language implementors struggle with specifications. Those writing to a spec generally want to follow it, but unlike the authors of the spec, they face problems of implementability. When a standard specifies a feature that is too difficult to implement, or that interferes with performance or other desiderata, some implementors will simply omit it, whatever the language standard says.
Scheme has two features that are particularly annoying to implementors, because they affect how procedure calls are compiled: call-with-current-continuation and tail call optimization. Many implementations, particularly those that aim to interoperate with another language, don't implement them. In JScheme and Kawa, continuations only work outward: call/cc is call/ec. Kawa optimizes local tail recursion, but not tail calls in general. Their implementors would have preferred to follow R5RS, but they decided it was not practical to do so — they felt performance and compatibility with Java were more important than strict compliance with the standard.
To reduce the burden on implementors, the Scheme Reports have long declared some features optional. Most of the numeric tower is optional, and various standard procedures have been marked as optional in some versions. This has been a great help to implementors, who have been able to implement Scheme without worrying about little-used features like complex arithmetic, and has probably contributed to the large number of implementations.
Full continuations and nonlocal tail-call optimization are also little-used features — despite their general utility, few programs rely on either. Implementors know this, which is why they're willing to omit them, even if the standard does not. Users do not appear to consider this omission a serious flaw; JScheme and Kawa are generally considered serious, full-featured implementations, not incomplete toys. In existing practice, call-with-current-continuation and tail call optimization are optional.
Oleg has already proposed making call/cc officially optional, and I agree. Implementors and users treat it as optional, so the standard should too.
In Oleg's proposal, both call/cc and dynamic-wind are optional, and can be omitted entirely. This is unnecessarily disruptive, as it breaks the many programs that use call/cc only for escape continuations and dynamic-wind only for unwind-protect. I suggest a more conservative change: require call/cc to provide at least escape continuations, but make full reusable continuations optional. (There should be a cond-expand feature for this — full-continuations? full-call/cc? reusable-continuations? indefinite-extent-continuations? Just call-with-current-continuation?) This preserves compatibility for almost all programs, while removing one of the greatest burdens on implementors, so there will continue to be many good implementations of Scheme, even as it standardizes other implementation challenges like define-record-type and parameters and exceptions.
The same goes for other features that are difficult to implement. If neither implementors nor users think a feature is necessary, the language standard should acknowledge this, rather than condemn part of its community as noncompliant.
If we put something in a library, there's no need for a cond-expand feature, because the existence of a library is something R7RS cond-expand can already test for.
ReplyDeleteBut seriously, guaranteed tail calls and call/cc are the two features that make Scheme different from all other Lisps. If you want other Lisps, you know where to find them. For that matter, it would be easy to implement a NotQuiteScheme in Common Lisp if it's the hygienic macros or the standard procedure names you like.
Continuations and tail calls were the historical origin of Scheme, but I think they're not what most Schemers care about. When people praise Scheme, they usually describe it as a small, clean Lisp, and while this is partly convention, it probably reflects what they like about the language. ISLISP or EuLisp might serve as well, but it's harder to find implementations of them.
ReplyDeleteOne of my bucket-list projects is to create a couple of new ISLisp implementations, one in Common Lisp (to replace KMP's) and one most likely in Java (though there have been rumblings about an LLVM-based system).
ReplyDelete