racket-r7rs VS guile-prescheme

There's PreScheme, which is a restricted dialect of Scheme that compiles to C. I haven't used it, but it seems like C with Lisp syntax. It has no support for closures, garbage collection, or first-class continuations. Vectors aren't bounds-checked. Types are inferred using Hindley-Milner type inference.

https://groups.scheme.org/prescheme/

It's old, and it seems like no one had written anything related to it in 20 years until in 2022. Now, there seems to be a port of PreScheme from Scheme48 to Guile Scheme at the moment.

https://gitlab.com/flatwhatson/guile-prescheme/

I agree. I've been searching for solutions for a while. A few choices: - Common Lisp Coalton, very similar to Haskell. - Hackett, a Haskell-like DSL implemented in Racket. Licensing would be an issue, so it would have to be ported to Guile Scheme if you want to build an Emacs out of it. This is not easy since it takes advantage of several Racket-specific language features. - Shen, which can be built on top of Common Lisp, Scheme, Racket, or even Emacs Lisp. The drawback is that it is a fairly cryptic language, and extending foreign language bindings is not well documented. You would basically have to program the entirety of Emacs from scratch - PreScheme is a statically-typed (Hindley-Milner family) subset of Scheme that compiles to C. Originally written to build the Scheme-48 compiler, it is being ported to Guile. Not production read yet. - Zile is an editor engine built on Guile 2.0. But there is no static typing or algebraic data types, it is simply a replacement for Emacs written in Scheme from the ground-up. It needs to be ported to Guile 3.0. Guile 3 has an Emacs Lisp interpreter built-in, but it needs to be developed further before it could run more popular Emacs Lisp applications like Org-Mode or Magit.

[PreScheme](), a subset of Scheme with static type checking and Hindley-Milner type-inference, compiles to the C programming language, and has a runtime that does not require a garbage collector at the expense of eliminating a few useful features from the Scheme language. (presentation at FOSDEM 2023, currently being ported to the Guile Scheme platform on gitlab).

The Internet is an easy target for blame, but in fact in the past month I found a number of people whose thinking (at least on some specific topic) was near to mine through Reddit discussions (and now you, it seems):

https://www.github.com/kaveh808

https://gitlab.com/flatwhatson/guile-prescheme

If you are interested in the nature of machine code and assembly language I would recommend at least looking at Scheme86:

https://dspace.mit.edu/handle/1721.1/6042

It's like a Scheme interpreter running on hardware, and the latest successor to Steele/Sussman's Scheme-on-a-chip--I'm working on microcoding it with my inferior S-assembly. :) I didn't think you were being insulting--my last refuge in an increasingly humorless world appears to be self-deprecating humor.

Have you reached out to John Cowan, who is working on the R7RS Large Scheme standard, and is interested in topics like auxiliary human language as well as computer language and their representation? I'm not serious enough, I'm afraid, for the Scheme community (see above)--but they might take you more seriously:

https://en.wikipedia.org/wiki/John_W._Cowan

I have been meaning to re-install Whitaker's Words which I used frequently in my own study of Latin, but lost when I upgraded my OS. You might have heard of Ido, an auxiliary language designed by Louis Couturat, a French logician, and the successor to Esperanto. It's almost completely regular, and I thought it might be a start for a more human-language neutral Scheme implementation (it is a Eurocentric language, unfortunately). My middle-school English teacher in 1981 pointed at the Esperanto booth in the language arts faire we took a field trip to and said, "I don't know why that booth is always so disappointingly unattended." I guess "ain't much changed", right?

I recommend "Asimov's Guide to Shakespeare" if you haven't read it:

https://en.wikipedia.org/wiki/Asimov%27s_Guide_to_Shakespear...

and maybe we should both just continue to choose "to be" rather than "not to be".