Roadmap for higher-level utils? Perhaps start a separate package?

[leftaroundabout]

Although the fact that HaTeX uses Haskell syntax already is a significant advantage for writing documents in it (as opposed to in LaTeX itself), “raw HaTeX” also has a few issues that keep bugging me:

Math is unsafe

For one thing, LaTeX makes a pretty rigid distinction between math mode and normal mode, but in HaTeX both are the same type. On one hand, you might say it's futile to “make LaTeX type-safe” because of the self-modifying nature, OTOH, whereas the vast majority of LaTeX documents don't really use any such syntax-modifying features, very many of them do use math mode.

In math mode, HaTeX is rather awkward, being not parenthesisation-aware. I'm personally quite happy with my TeXMyMath package, however this makes heavy use of unicode which I suspect not many users are keen on.

Citations are cumbersome

The LaTeX workflow for citations is to keep a .bib file that contains extensive information on every source you wish to quote – necessarily at least all the info that should appear in the rendered document – and then use keys into that .bib file in the document. Of course there are bibliography tools that can help creating these .bib files, but it's still always either a lot of duplication or your documents aren't standalone.
Nowadays, there is with DOI a clearly established standard for how documents can uniquely and minimally identified, so what I'd like is to only include the DOI directly in my document, and have all the details done automatically in the background for me.

I wrote a monad transformer for this and it works in a sense – in each document, you just need to specify the DOI, though you still need to refer to a master .bib file. Which kind of defeats the point. And even so, it incurs a dependency on a parser for .bib files, which aren't part of LaTeX per se.

Doing it properly would require much heavier dependencies – network access, and/or configuration management to retrieve and/or store the info of what a DOI refers to.

What package does this command belong to?

HaTeX doubles the effort of including packages: you need a Haskell import clause to get access to the commands, and then you still also need to put the usepackage into the document preamble. The latter sometimes requires a particular order of package-imports, because many LaTeX styles use pretty adventurous monkeypatching.

It would be much nicer if each command in HaTeX “knew” what package it belongs to, and a document could assemble its own preamble simply based on what commands it contains. This too would be possible with a monad transformer, but it would require some non-obvious decisions:

• How would we identify packages?
• How to know that e.g. breqn needs to be included after amsmath?
• Should the information be stored in the syntax tree? (Probably not)

---

The question is, how best to move forward. Suggestions as separate comments...

[leftaroundabout]

Add a new package (HaTeX-plusplus?) “for everything shiny” to the repository

This could carry an “advanced & unstable” disclaimer. It could be a sandbox for ideas, incur heavier dependencies, but still be in sync with the main package to allow changes to the basic definitions be done if necessary (hopefully, in a backwards-compatible manner). For instance, the “package-aware commands” might require an extra method to the LaTeXC typeclass.

[leftaroundabout]

Add a fork (HaTeX-prime?) either to this repo, or a different one

This would be an alternative to HaTeX, with more advanced features. Patches could still be exchanged with HaTeX, but there wouldn't be a direct synchronisation.

Disadvantages include: dependent 3rd-party packages would need to choose. Or else we'd additionally need a “meta-HaTeX“ package, using backpack.

[leftaroundabout]

Just add stuff to the HaTeX package as it is

Perhaps I'm overthinking all of this. However, I reckon it is valid to want the base HaTeX package to be kept stable and somewhat minimalistic.

[leftaroundabout]

Keep the entire HaTeX project small

...and leave more advanced features to third parties.

[Daniel-Diaz]

Thanks for the extensive explanation!

I guess I'll start with what I wouldn't want: forking HaTeX. I would prefer adding new features on top of what we have instead of creating two similar options for the user, plus having to keep merging updates to keep both forks up-to-date.

Between adding the advanced features to HaTeX or creating a new package for this purpose, I would choose the latter.

Most of the problems you are describing are the consequence of the intention of not trying to achieve too much with HaTeX. HaTeX started with a clear, simple purpose: implement the LaTeX syntax in Haskell. It's true that it is currently more than that. Things like the modules for TikZ add convenience beyond just helping with the syntax. It might be hard to tell where to draw the line. Maybe the line is "can this be implemented using only LaTeXC"? If not, you've crossed the line.

Now, in the option of adding advanced features outside of the HaTeX package, I see two ways of doing it:

1. Have a single repo (edit: package) for HaTeX' advanced features.
2. Have a repo (edit: package) for every big new feature (HaTeX-doi, HaTeX-math, etc). This would mean more fine-grained control for the user, but more maintainance burden.

However, something like the monad that keeps track of LaTeX package imports and that might include other convenient features, should be I think in a central package that is imported by all those advanced features (doi, math, etc).. I foresee it being useful for all of them. That central pakage could be HaTeX itself.

Having said all this, I would like to make a further proposal. You are already quite familiarized with HaTeX and all its parts, and you're probably the biggest contributor these days. Would you consider becoming a co-maintainer? I think it would be for the best for HaTeX!

Thanks again for your valuable contributions!

[leftaroundabout]

Well, thanks for the project maintenance so far, for valuing contributions, and for trusting me (even if some of my ideas are, I suppose, a bit on the wild side)! Alright then, I would take on co-maintainership. But I suppose you'd prefer I still raise bigger points first as issues here, rather than rushing changes by myself?

As to this question – well, I'm really not sure what would be the best option. But I don't see what the advantage of splitting up the project into multiple repositories would be. If the new packages would stay closely to the main one, then I think it would be just as good to keep them all in the same repo.

[Daniel-Diaz]

Yes, of course, important changes need to be discussed. Glad to have you on board!

Even if I typed "repo", what I actually meant was "package"... hehe

[jorsn]

HaTeX doubles the effort of including packages: you need a Haskell import clause to get access to the commands, and then you still also need to put the usepackage into the document preamble. The latter sometimes requires a particular order of package-imports, because many LaTeX styles use pretty adventurous monkeypatching.

Have you thought about using effects libraries, e.g. the package polysemy? I haven't used them so far, but it seems that they'd make it easy to add each LaTeX package as an effect providing its own set of applicable functions. Unlike monad transformers, order of effects matters, wich is realized in polysemy via a type-level list, I think.

This could be used as a substitute for monad transformers, but probably also additionally. It should be possible to create a HaTeX-effects package providing an effectful HaTeX type and prelude on top of HaTeX.