Re: How to classify Scheme implementations on Scheme.org Lassi Kortela 15 Feb 2021 22:11 UTC
> Although I have strong opinions about the proper use of terms such as “Scheme” and “R7RS”, you should only view my comments as my personnal position on the matter. I don’t claim to represent the whole Scheme community nor am I the administrator of the site. So please read the following with that in mind. Since you are one of the most experienced schemers, your opinion rightly carries more weight than ours. We appreciate that you are involved in these discussions and that you check our work against howlers. We are inexperienced and will certainly get something wrong once in a while. Proper tail calls + continuations + syntax-rules does seem like a good baseline benchmark. Syntax-rules is the simplest and most standard implementation of hygienic macros, another feature almost unique to Scheme. Bigloo (targeting C and JVM), Kawa (targeting JVM), and IronScheme (targeting CLR) are prominent implementations generally referred to as Scheme, that may have some trouble with proper tail calls and continuations due to the limitations of the target platforms. If I've understood correctly, it's easier to do just tail recursion for JVM/CLR than to do fully general tail calls. Here are some pertinent quotes (some of which may be out of date): From https://www-sop.inria.fr/indes/fp/Bigloo/manual.html "Bigloo produces C files. C code uses the C stack, so some programs can't be properly tail recursive. Nevertheless all simple tail recursions are compiled without stack consumption." From http://community.schemewiki.org/?bigloo "Bigloo is a Scheme implementation designed to be much more static, like C++, than most other Scheme environments. It also implements call-with-current-continuation very poorly: not only is it implemented by copying the stack on every continuation capture, but the compiler also requires that compilation of any module that uses the operator be preceded by a special option that cripples many optimizations that the compiler would otherwise have made." From https://www.gnu.org/software/kawa/Compatibility.html "Also, call-with-current-continuation is only “upwards" (?). I.e. once a continuation has been exited, it cannot be invoked. These restricted continuations can be used to implement catch/throw (such as the examples in R4RS), but not co-routines or backtracking. Kawa now does general tail-call elimination, but only if you use the flag --full-tailcalls. (Currently, the eval function itself is not fully tail-recursive, in violation of R5RS.) The --full-tailcalls flag is not on by default, partly because it is noticably slower (though I have not measured how much), and partly I think it is more useful for Kawa to be compatible with standard Java calling conventions and tools. Code compiled with --full-tailcalls can call code compiled without it and vice versa. Even without --full-tailcalls, if the compiler can prove that the procedure being called is the current function, then the tail call will be replaced by a jump. This includes must “obvious” cases of calls to the current function named using define or letrec, and many cases of mutual tail-recursion (including state-machines using letrec)." From https://en.wikipedia.org/wiki/IronScheme "IronScheme was planning to build upon the Microsoft Dynamic Language Runtime, but decided to abandon this idea because the DLR branch the project used became out of sync with the trunk, and also because the DLR, according to the developers, could not support the majority of the Scheme's requirements. IronScheme eventually made a limited use of its own version of the Microsoft's DLR, but it had to patch it to be able to implement some required Scheme features like tail call elimination." From https://xacc.wordpress.com/2008/11/03/ironscheme-does-cps/ "After a week or 2 of struggling, IronScheme is slowly but surely getting CPS support that will enable full first-class continuations (iow, the can be re-invoked multiple times)." "Also note, with this version the entire Scheme source gets converted to CPS, and results in a bootfile roughly 2,5 times the previous size. Not sure about performance currently."