Re: implementation language [was: library for unicode collation in C for texi2any?]

[Patrice Dumas]

On Thu, Oct 12, 2023 at 10:25:23AM -0700, Per Bothner wrote:
> On 10/12/23 02:39, Patrice Dumas wrote:
> > There is a translation to C of texi2any code going on, for the future,
> > after the next release, mainly for the conversion to HTML in a first step.
> 
> I've always thought that C++ is the obvious implementation language for 
> texi2any.
> The structure of the Perl code is probably a lot easier and cleaner to map 
> into C++
> (using classes and simple single inheritance) than to plain C.

Mapping perl to C is not that difficult in my experience, after the work
Gavin did on the parser.  There is only one thing that I miss, this is
some hash map.  It is always possible to use an array and linear search,
but an efficient hash map would be more natural in some cases.  Some
namespacing can also be useful, but it is not such an important feature
as it can also be easily done by choosing an appropriate naming
convention.  I avoid inheritance as much as possible, it makes the code
much harder to follow and maintain, in my opinion.

> C++ has a more extensive and useful standard library than C.

I guess there is an hash map, but I am not sure that we would need much
more.
 
> Re-writing texi2any in Perl turns out to have been a mistake; switching to C
> seems like it would be another mistake. But hey - I'm not the one doing the 
> work.

I am not a good judge, but it is unclear to me that the rewriting in
perl was a mistake, it allowed to have the current design, which I
believe is much better than the design of makeinfo in C had.  It is
easier to redesign in a high level language and then translate the parts
than need to be sped up to a low level language than do everything in a
low level language.

>From the perspective of texi2any design, to me it is a good thing to
have both a high level language (perl here for historical reasons
mostly, but could be something else) and a low level language for speed
(C in texi2any).  Both high level and low level languages have their uses:

1) High level language is best for code that is executed only a few time
   to need less time to code (main program, code related to
   customization).

2) High level language is used for customization (of HTML) for
   user-defined functions that replace default formatting functions

3) High level language is used for converters that are not used often
   (conversion to Texinfo XML, to LaTeX until it becomes more used),
   to limit the time needed to do the code.

3) low level language is used to speed up repetitive treatments.  Non
   repetitive computations are also written in low level language
   to avoid too much going back and forth between high and low level
   languages.

This means that the high-level language need to be able to call the
low level language and the low level language also need to be able to
call the high-level language.  Using Perl and C is the current
combination, for historical reasons and because of the knowledge and
preferences of the persons who volunteered to keep on developping
makeinfo/texi2any.  Other combinations could be used in theory,
depending on the possibilities offered by the languages in term of
bindings but, in practice, it depends more on volunteers.

It also seems to me that using C or similar (maybe C++ is C compatible
enough) as low level language is probably a good choice, as bindings
should exist for all languages, I am not sure that it is the case for
other low-level languages.  Perl could be replaced by another high level
language, it works well for texi2any in my opinion, but the difficulty
here seems more than not that many people are willing to use it and
develop with this language.

In the long term, when we have enough C code to do most of the work,
maybe it could become possible to develop bindings for other languages
than perl such that there is a larger choice to develop converters.  But
this would not be so usefull, if there is nobody actually interested by
doing converters whatever the language.

-- 
Pat