Would Mogan benefit from bundling a faster Scheme implementation, or what is the rationale behind choosing s7?

[9ao9ai9ar]

Is your feature request related to a problem? Please describe.

There was a review done in circa 2018 comparing various Scheme implementations in view of modern scientific needs, which was later published in ICFP 2020. It drew its candidates from the top performers on R7RS Benchmarks then that were also available as Debian packages. Six years have passed since then, but nothing much has really changed: the fastest Schemes are still Chez Scheme (R6RS) followed by Gambit (R5RS/R7RS).

Since a key benefit of using Mogan is the faster performance, could performance be further improved noticeably by switching Mogan's Scheme engine to one of the aforementioned industrial-grade Scheme implementations? (By the way, I think S7 Scheme on that page should be clarified to be Goldfish Scheme, based on s7.)

Describe the solution you'd like

Quoting Why we created Goldfish Scheme:

Goldfish Scheme is implemented to overcome the defects of S7 Scheme:

1. Distribute the ready-to-use Goldfish Scheme interpreter and structured REPL on Linux/macOS/Windows
2. Try to implement the R7RS-small standard
3. Try to provide the useful SRFI in R7RS library format

it seems the problems would be solved automatically by switching to Chez Scheme, or Gambit if you really want to be based on R7RS, though I have no experience whatsoever with either.

Could you please outline the reasons for the current choice and if there are plans to migrate to a different Scheme in the future?

Describe alternatives you've considered

No response

Additional context

No response

[mgubi]

it is not so simple. I discussed some tradeoffs here: https://texmacs.github.io/notes/docs/scheming.html

at some point I've started also to integrate Chez, but it is not designed to be integrated and my current attemp crashes the machine. Also, if you want to ship to web assembly Chez is not an option, an a small project like S7 is ideal.

Another interesting interpreter is FemtoLisp (but needs some adaptation). Ultimately I guess we would need to develop our own interpreter (or modify a bit the way TeXmacs use scheme, which is very peculiar and tuned on the behaviour of Guile 1.8)

[mgubi]

Speed is not fundamental, but I guess having some JIT would improve a lot. But again this would be difficult to ship to web assembly, and in my opinion web assembly can be an important aspect of the future of TeXmacs.

[9ao9ai9ar]

it is not so simple. I discussed some tradeoffs here: https://texmacs.github.io/notes/docs/scheming.html

Interesting. Didn't know TeXmacs has a working implementation in Guile 3 already, which should seamlessly integrate with Guix System. Maybe an article on the status of WebAssembly support in various Scheme implementations, too?

[mgubi]

To my knowledge there only scheme interpreters work on webassembly (via emscripten). However if the interpreter is not fast you will have an additional speed penalty from the webassembly translation. From https://ecraven.github.io/r7rs-benchmarks/ you can well see that the only competitive interpreters are S7 and femto-lisp (Guile 1.8 is slower than both of them, apparently). The interpreter in Guile 3 is at the same sped as that of Guile 1.8 last time I checked. The Hoot project https://spritely.institute/hoot/ is building a webasm backend for the guile compiler, but this does not mean (yet) that you have a scheme interpreter in webasm (and speed will be still an issue). https://www.biwascheme.org is a scheme in javascript which could run in the browser, but I guess will be complicated to interoperate with TeXmacs. So from my point of view it remains only S7 (or maybe a stripped down version of Guile 1.8). Comments/remarks are welcome.

[da-liii]

Could you please outline the reasons for the current choice and if there are plans to migrate to a different Scheme in the future?

@mgubi ported GNU TeXmacs to Guile 3/Chez Scheme/S7 Scheme several years ago.

I tried the Guile 3 port by mgubi first, and found that Guile 3 does not support Windows well. The Guile 3 branch was actively maintained by @hammerfunctor .

And then I tried the S7 Scheme port by mgubi, it works fine, and based on S7 Scheme, I started the Mogan project, a distribution of GNU TeXmacs using S7 Scheme instead of GNU Guile.

And I haven't started trying the Chez Scheme port by mgubi. For me, S7 Scheme is good enough. And because Chez Scheme is still using R6RS, and I prefer R7RS, I think S7 Scheme is already the best choice for a GNU TeXmacs distribution.

I think conforming to the R7RS standard is important, while the author of the S7 Scheme does not think so, he has his special taste on the features and behaviors of a Scheme implementation. I think it is necessary for me to create Goldfish Scheme based on S7 Scheme.

A fun fact is that I found that SRFI 1 in Scheme is really close to the Scala standard library api (or vice versa). I feel at home when I write code in Scheme as a Scala fan.

Li Haoyi (@lihaoyi )'s work on migrating the Python standard library styles to Scala inspires me, that's why I'm trying to migrating the Python standard library to Goldfish Scheme:

• https://github.com/com-lihaoyi/os-lib
• https://github.com/LiiiLabs/goldfish/blob/main/goldfish/liii/os.scm