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.
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).
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.
Bruno
[1] https://www.gnu.org/prep/standards/html_node/Source-Language.html
[2] https://lists.gnu.org/archive/html/info-gnu/2025-04/msg00000.html
[3]
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=tree;f=gettext-tools/examples/hello-rust;hb=HEAD
