Re: m4p: an implementation of GNU m4 in Python

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