HaTeX 3.6: Proposal for Texy class

Description

This is a proposal for a new feature I would like to see (and implement) in HaTeX for its next version. It consists in a new type class, with tentative name Texy (tex-like or tex-ify shortened). Other names are to be proposed, if any other better is found. The class would contain every type whose values can be pretty-printed in LaTeX form. Therefore, the definition of the class would be as follows:

class Texy t where
  texy :: LaTeXC l => t -> l

We can also make Texy a subclass of Render, so we can have a default implementation using rendertex.

class Render t => Texy t where
  texy :: LaTeXC l => t -> l
  -- Default implementation
  texy = rendertex

But I am not sure if this is suitable. The purpose of Texy is to build, from Haskell values, more complex LaTeX expressions than just rendering to Text, which, in the other hand, it is no more than a Show instance after all. It may work with numbers but not with more complex values like fractions or matrices.

Applications

A first application could be Rational pretty-printing as fractions using the frac function. However, we also have a problem here: the constructor % for rational numbers is already in use in our library. Perhaps we should rename the comment operator to %:? I have not seen an extensive use of this operator yet.

We would also be able to create LaTeX values for tuples, resizing the parenthesis in the tuple appropriately using autoParens.

Another application, perhaps more sofisticated, is pretty-printing matrices. Since the elements of the matrix would be a Texy instance as well, we can use texy to pretty-print to LaTeX matrices which may contain fractions or any other user-supplied value. This is an interface much more flexible than the current one (using a plain Render instance for the elements).

When rendering trees (see Text.LaTeX.Packages.Trees.Qtree), we are already using a LaTeXC l => (a -> l) parameter in order to pretty-print the elements of the tree. This is a more free version of the Texy class, which allow the user to supply different ways to generate LaTeX values from a single type. However, this is not a point against the current proposal, since this functionality can be kept as it is and added wherever is needed.

I honestly think this would be a good improvement.