On Wed, Oct 16, 2024 at 09:29:47AM +0100, Gavin Smith wrote: > On Wed, Oct 16, 2024 at 08:16:35AM +0300, Eli Zaretskii wrote: > > > From: Gavin Smith <gavinsmith0...@gmail.com> > > > Date: Tue, 15 Oct 2024 22:22:45 +0100 > > > Cc: bug-texinfo@gnu.org > > > > > > I can imagine that at some point we will abandon the Perl version of > > > some code, requiring XS to use texi2any. > > > > One problem with doing that is that the distributed binaries of > > Texinfo will require a very specific version of Perl -- the one > > against which the XS modules were compiled. In practice, this means > > that distros will need to make a specific Perl version to be a > > prerequisite for upgrading Texinfo, because distributing Perl binaries > > with Texinfo is not practical. > > > > On MS-Windows, this is even more problematic, because there are > > several incompatible ports of Perl to Windows. That is the reason why > > I always remove the XS modules from the binary distributions I put on > > ezwinports site -- I cannot possibly distribute the binaries of Perl I > > use to compile XS, and cannot even hope people are likely to have the > > same Perl installed. With texi2any automatically falling back to Perl > > when XS modules cannot be found this is just a performance issue, but > > if Texinfo requires XS, this would mean users will be unable to run > > makeinfo in such cases. > > In that case it's likely we'll have to keep on maintaining C and Perl > code side-by-side for as long as the program is written in Perl, even if > this makes making changes in the program more difficult.
Any replacement for Perl should have the feature that we can avoid having dual implementations of some code (e.g., XS versus pure Perl). I learned that for Python, there is something called the "Python stable ABI" which there appears not to be an equivalent for for Perl. It is still limited, though: CPython’s Application Binary Interface (ABI) is forward- and backwards-compatible across a minor release (if these are compiled the same way; see Platform Considerations below). So, code compiled for Python 3.10.0 will work on 3.10.8 and vice versa, but will need to be compiled separately for 3.9.x and 3.11.x. https://docs.python.org/3/c-api/stable.html Probably not worth rewriting in Python to get this very slight benefit of broader ABI compatibility. Of course, a compiled language (Go, Rust, C++) wouldn't have this problem at all - the entire compiled program could be distributed with no dependencies on the version of an interpreter. I know that C++/C hybrid programs are possible. I'm led to believe that Rust/C hybrids are also possible (although I don't know a great deal about Rust). I gather that Go/C hybrids are problematic and not particularly recommended (just based on what information I've been able to surmise based on a cursory search of the web, although I could be missing important information). I'm not aware of other candidate languages.
