Architecture of the Lua code

[projetmbc]

Could it be possible to propose another architecture for the Lua code? I would like to try to factorize the code, if it is possible. :-)

[josephwright]

I think a sense of what you are imagining would help to give an answer!

[projetmbc]

In broad terms, I just thought I'd go over the organization of the code and possibly do the following.

1. Abstract the code to make it easier to read and maintain. For example, the part about cleaning up the code can be simplified, I think.

2. Perhaps the use of "modules" would also make it easier to understand, and especially to maintain, the code.

My question is more about accepting or rejecting this type of changes.

In the end, all this remains a matter of taste... :-)

[josephwright]

1. Abstract the code to make it easier to read and maintain. For example, the part about cleaning up the code can be simplified, I think.

I'm still not clear what you mean: could I have an example?

2. Perhaps the use of "modules" would also make it easier to understand, and especially to maintain, the code.

This has been suggested before, but as part of quite extensive changes, and we were not seeing the real benefits. What's important, really, is to remember that l3build code isn't expected to be loaded by anything else. So making parts self-contained is OK, but it's not been a priority.

---

I think the broad position is we're happy to look at PRs, but as l3build works they've got to offer something reasonably 'obvious' in terms of making life easier (@zauguin, @u-fischer, @davidcarlisle agreed?).

[projetmbc]

Here is a very small example extracting from https://github.com/latex3/l3build/blob/main/l3build-check.lua#L106 .

Let's consider this chunk of code.

    -- TeX90/XeTeX knows only the smaller set of dimension units
    line = gsub(line,
      "cm, mm, dd, cc, bp, or sp",
      "cm, mm, dd, cc, nd, nc, bp, or sp")
    -- On the other hand, (u)pTeX has some new units!
    line = gsub(line,
      "em, ex, zw, zh, in, pt, pc,",
      "em, ex, in, pt, pc,")
    line = gsub(line,
      "cm, mm, dd, cc, bp, H, Q, or sp;",
      "cm, mm, dd, cc, nd, nc, bp, or sp;")
    -- Normalise a case where fixing a TeX bug changes the message text
    line = gsub(line, "\\csname\\endcsname ", "\\csname\\endcsname")
    -- Zap "on line <num>" and replace with "on line ..."
    -- Two similar cases, Lua patterns mean we need to do them separately
    line = gsub(line, "on line %d*", "on line ...")
    line = gsub(line, "on input line %d*", "on input line ...")

A loop over a dedicated "config" table can simplify these lines which all do a line = gsub(line, old, new). If one day there is another gsub to apply in this context, we just have to update the dedicated "config" table.

[josephwright]

Here is a very small example extracting from https://github.com/latex3/l3build/blob/main/l3build-check.lua#L106 .

Let's consider this chunk of code.

    -- TeX90/XeTeX knows only the smaller set of dimension units
    line = gsub(line,
      "cm, mm, dd, cc, bp, or sp",
      "cm, mm, dd, cc, nd, nc, bp, or sp")
    -- On the other hand, (u)pTeX has some new units!
    line = gsub(line,
      "em, ex, zw, zh, in, pt, pc,",
      "em, ex, in, pt, pc,")
    line = gsub(line,
      "cm, mm, dd, cc, bp, H, Q, or sp;",
      "cm, mm, dd, cc, nd, nc, bp, or sp;")
    -- Normalise a case where fixing a TeX bug changes the message text
    line = gsub(line, "\\csname\\endcsname ", "\\csname\\endcsname")
    -- Zap "on line <num>" and replace with "on line ..."
    -- Two similar cases, Lua patterns mean we need to do them separately
    line = gsub(line, "on line %d*", "on line ...")
    line = gsub(line, "on input line %d*", "on input line ...")

A loop over a dedicated "config" table can simplify these lines which all do a line = gsub(line, old, new). If one day there is another gsub to apply in this context, we just have to update the dedicated "config" table.

Perfectly reasonable: the current structure reflects the fact that we simply collect up normalisations as we go, and to a reasonable extent they are just randomly dropped into the file. (The ones that do have order significance are obvious I think.)

[projetmbc]

I think the broad position is we're happy to look at PRs, ...

I will do it in June at the same time I will implement a YAML option.

[MilfordBursonS]

Certainly, it's definitely possible to propose another architecture for the Lua code to try and factorize it. It's always a good idea to explore different approaches and see if there's a more efficient or organized way to structure the code. Do you have any specific ideas or approaches in mind for how you would like to factorize the code?

[projetmbc]

Without having read the code in detail, I have nothing concrete to propose, but it would be necessary to see if the articulation of the source files, and the use of modules, would not allow by isolating the functionalities to make the code easier to maintain.

I'll come back with concrete information via a request in June.

[projetmbc]

There is a package https://github.com/api7/lua-tinyyaml that could be used to implement the YAML file option. Is it a good idea?

[davidcarlisle]

ths question would be better asked in #280 I think. I don't see any consenus towards adding yaml there