Discussion: Feasibility of supporting Scheme-family scripting (eg. Guile or s7)

Summary

I’m interested in discussing the possibility of supporting a Scheme-family language, specifically Guile.

My reasons are:

Scheme languages have minimal cores, making them one of the most embed-friendly Lisp variants.

Lisp macros offer very flexible extension capabilities.

Guile and Scheme’s TinyCLOS provide OO features that feel conceptually close to Rust’s traits, which seems appealing for game logic.

Lisp languages naturally separate data and objects, which aligns well with an ECS architecture.

The functional style also feels compatible with Bevy’s API style, which already has a somewhat functional flavor.

So I’d like to explore the feasibility of Scheme/Guile as a scripting language for Bevy—purely as a technical discussion.
If no one is interested in attempting bindings, I may try experimenting with them myself in the future.

Feasibility

All Scheme-family languages follow the same dynamic-language conventions and naturally support first-class functions, so their function-calling model can meet BMS’s requirements for dynamic function invocation.

Guile provides a mature C FFI that can be called directly from the host, and Rust binding projects already exist. Therefore, interoperability with Rust is feasible.

s7 can be compiled into a single C file, making it suitable for embedding. There are also relatively complete Rust bindings available, so interaction from the Rust side is largely workable.

Among other Scheme-family languages, there are also pure Rust implementations (such as Steel). Although these projects are still new and somewhat experimental, they demonstrate promising potential for embedding and language bindings in the future.

Overall, Scheme-family languages can meet BMS’s feasibility requirements in terms of dynamism, FFI capabilities, and first-class function support.

Treat this as a feasibility discussion for adding Scheme-family scripting to the Bevy scripting plugin. The issue names no repository files, tests, or implementation entry points; start by reviewing the existing scripting integrations and Rust binding approaches, with completion defined by an agreed feasibility and implementation direction.