Rewrite core.

[korsbo]

Internally, latexify operates mainly on strings that are being passed around. This works but it is starting to become limiting.

problems with the current approach:

• Low customisability. Customization of the results rely on kwargs being passed to some conditional within the internal functions. If explicit support has not been added for something, it can't be done.
• Sensitive testing. The only thing that can currently be tested is whether the output string matches some literal string. Tests are, therefore, sensitive to minor updates that affect the output string even if it does not really affect the resulting rendered equations. It becomes problematic to determine what should be part of the API. We could say that minor changes to the output could change with patch version releases and that they are not part of the API. But, then, external packages can't test their recipes in a stable way. However, the alternative is that most things in latexify can't be updated without a major release.

Proposed solution:

• delay the processing of strings to the very last part of the process.
• build the envs and equations using types instead.
• have methods for converting these nested types to latex. Do this modularly and allow for over-loading. That way, one can customise the output by overloading something like generate_string(op::Fraction) = "$(op.args[1])/$(op.args[2])" rather than the usual \frac.
• make it possible to output these types rather than a string. That way, one can do testing that is insensitive to formatting updates.

These ideas are still tentative and open for input.

[Luapulu]

How do you deal with statements that are mathemtaically identical to what the user specified, but quite different in notation? For example, julia has no nth root function, so when a user gives :(x^(1/3)), should that show up as an exponent or as the nicer root notation?

To solve these kind of problems, would it make sense to have latexify be mathematically aware to some degree and feed all expressions through some symbolic maths engine?

[korsbo]

such decisions are made through a bunch of conditionals so it would be pretty easy to add something like that by just checking if the exponent is approximately 1/3, etc. In the current rewrite prototype I'm working on it would be pretty easy even for a user to add custom such conditional - consequence pairs and your particular example might be a good default.

Some expressions are, however, rather indistinguishable and I don't think that they can safely and robustly be separated. One such example is the separation between typed array construction 'Float64[1,3]' and indexing x[1,2]. They both look the same, and indeed, the former is implemented as an overload of Base.getindex - hard to get around.