Re: texi2any implementation language

[Patrice Dumas]

On Wed, Jan 01, 2025 at 10:47:10PM +0000, Gavin Smith wrote:
> On Tue, Dec 17, 2024 at 12:18:37PM +0100, Patrice Dumas wrote:
> > 3) for the main program, translating most parts to C is probably
> >    relatively easy, and I will probably do it at least partly, little by
> >    little as we use teximakehtml more to debug, although it is low priority.
> >    However, because of HTML customization in Perl, going C (or C++) only
> >    would require an interface for Texinfo::Config and embedding a Perl
> >    interpreter, which is  more specialized code and I do not think that it
> >    will happen soon, especially if we keep a dual implementation for
> >    portability on platforms with ABI discrepancies.
> 
> If we embed a Perl interpreter for HTML customization, could texi2any
> go from a Perl program with optional extension modules written in C,
> to a C program with (optional?) extension modules written in Perl, if
> enough of it was rewritten in C?

So far, I did not try to make the C very dynamic, as it is harder than
doing it in Perl, but it would probably be quite easy to have conversion
functions be registered after dlopening a file, as all the needed
conversion functions customization can be achieved by registering some
function references in the converter_format_data table in
convert/converter.c, mimicking the Perl object oriented overriding of
the Texinfo::Convert::Converter needed functions, that are not that
many.

>  (I am not promising to help with
> rewriting it in C, though.)  It would be an "implementation language
> inversion".

Indeed, this is what I am developing right now.  It is low priority,
but it is also quite easy now that the embedding of the Perl interpreter
is done.

To me, the main advantage is that we have something working with Perl
and could generalize to other interpreted languages if needs be.

> I saw you have been rewriting more in C, with there now a file
> tp/Texinfo/XS/texi2any.c implementing the top level code for texi2any,
> although don't know what your plans are for this.

To continue until it is fully implemented.  It is almost done actually,
although there are still bugs and for now, it is slower than the Perl
implementation in some cases, I will investigate once all the tests
pass.

> The TexinfoXML, TexinfoSXML, IXIN and IXINSXML converters converters
> could be dropped (as I have said before), although these are the simplest
> converters so it wouldn't help a rewrite very much.

There is no issue with keeping some converters as Perl only, I think.

-- 
Pat