JavaScript interpreters Jakub T. Jankiewicz (12 Feb 2021 08:25 UTC)
Re: JavaScript interpreters Marc Feeley (12 Feb 2021 12:31 UTC)
Re: JavaScript interpreters Jakub T. Jankiewicz (12 Feb 2021 14:07 UTC)
Re: JavaScript interpreters Marc Feeley (12 Feb 2021 14:54 UTC)
Re: JavaScript interpreters Jakub T. Jankiewicz (12 Feb 2021 17:38 UTC)
How to classify Scheme implementations on Scheme.org Lassi Kortela (14 Feb 2021 07:52 UTC)
Re: How to classify Scheme implementations on Scheme.org Jakub T. Jankiewicz (14 Feb 2021 09:12 UTC)
Re: How to classify Scheme implementations on Scheme.org Lassi Kortela (14 Feb 2021 09:34 UTC)
Re: How to classify Scheme implementations on Scheme.org Marc Feeley (14 Feb 2021 12:54 UTC)
Re: How to classify Scheme implementations on Scheme.org Arthur A. Gleckler (14 Feb 2021 15:45 UTC)
Re: How to classify Scheme implementations on Scheme.org Jakub T. Jankiewicz (14 Feb 2021 16:23 UTC)
Re: How to classify Scheme implementations on Scheme.org Marc Feeley (14 Feb 2021 17:13 UTC)
Re: How to classify Scheme implementations on Scheme.org Lassi Kortela (15 Feb 2021 22:11 UTC)
Re: How to classify Scheme implementations on Scheme.org Lassi Kortela (15 Feb 2021 22:22 UTC)
Re: How to classify Scheme implementations on Scheme.org Marc Feeley (15 Feb 2021 22:36 UTC)
Re: How to classify Scheme implementations on Scheme.org Lassi Kortela (15 Feb 2021 22:40 UTC)
Re: How to classify Scheme implementations on Scheme.org Marc Feeley (15 Feb 2021 22:31 UTC)

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."