Wednesday, April 17, 2013

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.

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.