On Fri, May 9, 2025 at 11:13 PM Jacob Bachmeyer <jcb62...@gmail.com> wrote: > > 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/>)
No, I'm using CPython. Some of the slow down certainly has to do with my use of bytestrings (allocated even for trivial things like read-only slices). Another is that Python itself needs to load before the program runs, and the unit tests are small programs, so most of the time is spent doing that. I wouldn't care too much to optimize the Python version as it's meant to be didactic of how an m4 implementation would look like. > > 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. What does it mean to drift out from underneath? > 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. I'm not aware of this. I couldn't find good information online; I decided to look up Richard Stallman's talks to see if he mentions Rust, and in 21:19-23:16 of <https://techrights.org/o/2023/03/17/rms-talk-for-latest-perils/> he mentions the trademark copyright from the Rust foundation as his only issue and that he has no other opinion of Rust. Is this then the issue? Does it have to do with cargo? I could write this all in core Rust avoiding other packages. In any case, I can see a few paths moving forward: 1. Keep working on the Python fork as an alternative to those who have issues with GNU m4 (like compilation issues) or want to educate themselves on an m4 implementation. 2. Rewrite in Rust 1.49 so that when gccrs is up to speed it can be incorporated with the GNU project. 3. Rewrite in C++, or GNU Guile, or even another language. 4. Rewrite in modern Rust, and do not try to incorporate it with GNU (it's still free software). Regards, Nikolaos Chatzikonstantinou
