On Wed, Apr 16, 2025 at 12:17 PM Bruno Haible <br...@clisp.org> wrote: > > Nikolaos Chatzikonstantinou wrote: > > Thank you for the response. I should confess that I'm currently rewriting > > GNU m4 in Python, aiming for 100% compatibility with 1.4.19. I had the > > issue of implementing regexp() because Python doesn't have that syntax. I > > wrote a shim for regcomp() but then I realized it's incompatible. Now I > > wrote one for the GNU interface (re_* functions). > > > > How I ended up attempting to rewrite m4 is kind of long winded but in any > > case I was encouraged by seeming issues after recent compiler build > > failures. > > > > I'm hoping that this is a welcome effort? I'm expecting it to be done > > sometime within a month hopefully. I intend to use the Python > > implementation to then write a Rust one. Both will be GPLv3+ licensed. > > From my point of view, rewrites in any reasonable programming language > under GPLv3+ are welcome.[1] (The community has made negative experiences > with MIT/BSD/Apache-licensed rewrites in the past.) > > It is desired, though, that the original and the rewrite remain compatible. > We don't need fragmentation in the sense of different sets of supported > options, different behaviours of built-ins, etc. Standards are one of the > means of avoiding fragmentation, but given that GNU m4 is a superset of > POSIX m4, either > - GNU m4 ought to be standardized by a new POSIX revision, or > - implementors of rewrites should communicate regularly with the GNU m4 > maintainers, so as to retain compatibility.
For now I'm just concerned with 100% compatibility with 1.4.19. I want the Python implementation to be a go-to implementation for those who wish to study an m4 implementation. My goal after that is to use the accumulated knowledge to write a fast m4 implementation. I've just finished writing eval() and the regex functions. > Regarding the programming languages: > > While [1] says that for a low-level language "the best language to use is C", > the very existence of Gnulib shows its problems: > - Many platforms have outdated C interfaces in libc, > - Many vendors ship buggy implementations that are a hell of effort > to protect against. > In other words, "C + gnulib" is reasonable to use, whereas "C without gnulib" > is more painful from a developer perspective. > > Python is becoming more and more used instead of bash / sh in GNU. For > example, in the GCC tree, I see 97 Python scripts, compared to 71 shell > scripts. And gnulib-tool definitely profited a lot from being rewritten > in Python. > > Things might be different for the m4 rewrite, though, because scripting > languages (or, more precisely, languages which lack a native-code compiler > that makes use of type declarations) are known to be slow at character-by- > character processing. > > Go might be a good intermediate between Python and Rust, because it has > garbage-collection (like Python) and a native-code compiler with type > declarations (like C and Rust). I chose Python because it's easy for me and its popularity means that it'll be easy for others to study the source code. I have never used Go and I probably wouldn't be able to write m4 in Go without spending a decent amount learning it. On the other hand, I know some Rust and I've already written a fair amount of m4 in it, and it looks pretty neat I must say. > One problem I see with Rust is that currently it does not integrate well > with the GNU Build system, in particular with VPATH builds (see [3] for > an example integration). Any improvements on that front would be welcome. > > [3] > https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=tree;f=gettext-tools/examples/hello-rust;hb=HEAD What is the issue with VPATH builds? I read the comments in configure.ac of that link, it seems to copy certain files into the build directory and then uses cargo. Would you rather if it used rustc directly? Or would you rather if the copying process was better automated instead of the explicit .in input files? The very reason I got involved with m4 is because I'm trying to improve certain aspects of autotools, in particular support for Guile, but I can try to tackle support for Rust too. On the off-chance that Rust proves too alien to autotools I can instead use C++ for my optimized m4 implementation. Regards, Nikolaos Chatzikonstantinou
