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
