Re: Use "simple parsers" for translations again?

[Patrice Dumas]

On Fri, Nov 24, 2023 at 11:24:55PM +0000, Gavin Smith wrote:
> As I understand it, it is not any part of the state that is problematic
> to modify for simple_parser.  It is only the structures that are referred
> to when creating the simple parser:

I think so too.

> Many of these relate to the creation of new Texinfo commands, or indices.
> These structures should be the same for all of the parser objects used
> for translations so copying them (with dclone) for every single translated
> string is a waste of time.

I am not sure about that.  The underlying question is what limit we set
on the users defined translations.  This is very unclear to me, we could
imagine large/complex Texinfo code to be used in user defined
translations if they have, for example, repetitive parts that they want
to generate ahd have them different for different languages.

> It seems that we could stop these structures being modified with the
> addition of a flag on the parser (e.g. $parser->{'locked'} or
> $parser->{'simple'}).  Then check this flag any time:
> 
> * A new Texinfo command is to be defined (@macro, @alias, @definfoenclose).
> * A new index is to be added (@defindex, @defcodeindex).
> 
> Then the change to the state wouldn't be made if the flag was set, and
> possibly a warning message could be given too.
> 
> I can try to work on a patch for this if this approach sounds like a
> good idea.

The main problem I see is that it will slow down every run with those
additional checks.  Other than that this should be doable.

> > I think that the approach of having shared state is both unusual and not
> > correct. Another possibility, which could be better and allow some gains
> > too would be to reuse a parser instead without initializing it.  It
> > would still maybe need some more cleanup of state between runs, maybe
> > with a separate function that would do nothing in XS, such that it does
> > not need to be run when the parser is not reused.  This would also
> > probably be more similar to what should be the final XS implementation.
> 
> Reusing the same parser object, with cleanup in between, seems to me to
> be even less correct as it means that the whole parser object is being
> shared across translations, rather than just certain parts of it, making
> it more likely that something persists between translations (e.g. @anchor
> locations).

Right now it works well for the XS parser, so maybe there would be a way
to make it work with the perl parser, the objective being to avoid
reallocation and probably some specific codes that take time.

> I've still not had the time to investigate what is going on with this
> test.  Hopefully I'll get to it this weekend.
> 
> In general, it seems like we're making the program significantly slower
> for a theoretic and very unlikely use case.

I think that we should not put important restrictions on translated
strings, maybe we could forbid using @node and sectioning commands, but
it is not clear to me that there couldn't be use cases for those.

-- 
Pat