On 5/9/25 16:45, Nikolaos Chatzikonstantinou wrote:
[...] I'm worried about: 1. What mode GNU m4 opens files in; m4p always open in binary, potentially treating carriage return differently on Windows. 2. Sneaky bugs. The functions that I have not yet implemented are debug functions, so they probably will not affect production m4 macros. The changeword macro might be removed in future versions of GNU m4 and I might not implement it at all, not sure if anyone uses it. I have not had any benchmarks, but from roughly looking at how long tests take I'm measuring a 100x slowdown.
Have you tried running it with PyPy? (<URL:https://pypy.org/>)
I'm hoping to rewrite it in Rust later to address that.
Unfortunately, Rust has ... problems as a language and ecosystem. For reasons that are partially technical and partially political, the general view of Rust at the GNU project seems rather dim to me. (An "AI"-assisted switch to Rust was the April Fool's joke earlier this year.)
The political problems were bad enough to spawn a Rust fork (<URL:https://crablang.org/>) which amusingly has provided most of the logo for the ongoing efforts to implement a Rust frontend for GCC. (<URL:https://rust-gcc.github.io/>)
Rust should probably be considered unusable for GNU development until that GCC frontend is complete due to one of the larger problems with Rust: the Rust language drifts "out from underneath" existing code. That is not acceptable at GNU, but the GCC Rust-language frontend is expected to follow the same convention GCC uses for other languages where the standards have evolved with time.
I believe that their first goal is to implement Rust 1.49, which gccrs will continue to support into the indefinite future.
-- Jacob
