# Standard macros?

In this comment Yuhao Huang suggests we could start having some standard macros in algebraic geometry. I have two comments:

1. It makes sense to reserve some commands such as \Spec and \colim
2. It doesn’t make sense, I think, to fix the actual macros for these commands.

I think I can convince most of you to agree with 2. For example, I like to define

\def\Spec{\mathop{\rm Spec}}

but (and I am happy to get feedback) I am sure this is completely utterly totally wrong! And let’s not even talk about

\def\SheafHom{\mathop{\mathcal{H}\!{\it om}}\nolimits}

 

which I am sure you like to define with an underline or a squiggly underline. It is clear that we are never ever going to agree on the “correct” macro even for something as simple as \Spec. Right?

I think I can make some argument for 1, but I agree it isn’t so clear. Namely, wouldn’t it be nice if you could download another algebraic geometer’s latex code and run it locally on you machine with your own preamble? After all, my preamble is better than yours (as we’ve already discussed above).

Finally, many people define macros for things that take just one letter, typically with something like

\newcommand{\CC}{\mathbb{C}}

I may have done this myself in the past. But now I think just typing \mathbb{C} is just as fast and it makes it clear what you get. The argument that it is faster to change the macro doesn’t really hold water as you can do a search and replace (or run a sed command) quite easily. Moreover, the letter C is going to occur as blackboard bold, gothic, greek, german, calligraphic, italic, roman, etc, etc so don’t try to tell me that it is better to use a short macro because who knows which of \CC, \bC, \cC, \iC is the one you want? No, the only reason for having a macro for blackboard bold C is if you wanted to have a macro for the complex numbers. Then you would probably name it \ComplexNumbers or something long like that so you never get confused.

I guess then the question becomes: Is \ComplexNumbers a good choice for one of the standard command names? I’m not convinced.

Another aspect of the situation is that, if we are inclined to introduce the command \ComplexNumbers, then also some things that never get macros should get macros. For example there should probably be a macro (untested)

\def\DerivedCategory#1{\mathop{\rm D}(#1)}

because part of the value of having macros may be that it makes it easier for our LaTeX files to be parsed by machines in the future. Madness!

I hope there is a lot here you can disagree with. My stance on most of this stuff is that it is much easier to fix this kind of thing (if it turns out we made a bad choice of coding a symbol or whatever), than it is to add new mathematics. So essentially, it doesn’t matter, but I am still interested to hear if you more or less agree with what I said above. Leave a comment!

PS: Here is a complete list of the currently defined macros in the Stacks project: \lim, \colim, \Spec, \Hom, \SheafHom, \Sch, \Mor, \Ob, \Sh. You can find these in preamble.tex.

PPS: Of course there is the whole other issue of choice of macro names. As you can see above I have been tempted by the Capitalization Curse. Why didn’t we name the macros \lim, \colim, \spec, \hom, \sheafhom, \sch, \mor, \ob, \sh? I guess an easy way out is to simply have both?

## 6 thoughts on “Standard macros?”

1. Thanks for the quick response. I understand that it is hard to make macros “standard”. You mentioned the value of having macros. To me the point of introducing macros (in programming languages, as well as LaTeX), is to allow the language to evolve. (it did hide things under the rug and is easily broken if not used carefully, and most macro-expansions in familiar programming languages are not pretty at all.) As it fits the writer’s need better and better, and thus allow one to write quickly.

These kind of adaption must be accompanied by some “natural selection”, in this case it is the process of people accepting/using certain macros. It will be great for a macro if it is used in a huge project like this.

And I think there is nothing wrong with \newcommand{\CC}{\mathbb{C}},
(I did put more in my own macro: \newcommand{\CC}{\ensuremath{\mathbb{C}}\xspace}, but maybe it is not a good idea.)
as it is readable and widely accepted. It might be true its form not universally agreed, but its necessity can be seen from that in practice some people even introduce such to newbies of LaTeX, maybe to convince them LaTeX does not force one to type much more than necessary and is highly configurable.

As for the tex in the stacks project being usable for others, I can think of two ways to do this: either using some script to replace all macros, i.e. do a macro expansion in the actual latex, or put things in a package, like stacksproj.sty. The first solution is for people who want to copy the tex of a Tag to their own writing, the second is for people who want to work on the stacks project.

• OK, I completely disagree with what you say about \CC. If \CC means a blackboard bold C everywhere in your LaTeX file, then there already is a macro for that, namely, \mathbb{C}. It cannot possibly help you to introduce the macro, unless you are ridiculously slow at typing.

To put it even more strongly than in the blog post: I see no reason to introduce macros unless they have mathematical meaning. This may be what you were saying in your first paragraph.

It could improve the readability of the LaTeX files (for others as well as yourself). But in my experience, most people do not care at all about the readability of their LaTeX files. I in particular detest the habit of having extremely long lines in LaTeX files (but that may just be because I am a Torvalds groupie, see this line).

• One reason I use macros, like \CC, is that it makes it much easier to read my latex files, and I find I often do as much revising by reading the tex itself as I do with a PDF reader. I would also say that while it doesn’t take much more effort to type \mathbb{C}, the braces make it more prone to compilation errors.

• But is \CC a blackboard or boldface letter? What if you happen to use both in the same document? You now, at this point, what they mean, but you will forget. Probably it’s my computer science background, but I agree with Johan on this: meaningless two-letter macros should be avoided. I am guilty as charged to a certain extent, but I try to avoid them as much as possible. It’s a sign of laziness, and whenever I decide to change notation I blame myself for not using consistent descriptive macros.

As indicated, though it’s not final what for instance \SheafHom should look like (I don’t like the italics for instance, I prefer just calligraphic H) it is possible to agree on the *meaning* of a macro in this case: \SheafHom should always produce an *operator* that denotes the internal Hom in a category of sheaves. That is something you could “standardize”. Then people can write their own implementations for the standard macros and use the ones they like. I’d be interested in doing this experiment and see what the results are.

I don’t agree with the stanza of using as little macros as possible (although I can see the benefits in case of the Stacks project). For instance, I am really picky on not writing derived categories etc. with the standard italic, like it is currently done in the Stacks project.

This brings me back to what this post. If the formulas don’t contain the semantics it’s impossible to immediately change its layout. But on the other hand, its impossible to describe the semantics of a formula in a short way, just look semantic MathML… A good balance should be found, and I think the current state of the Stacks project is a little low on semantics in formulas.

2. Just added a new macro \NL. I reread what I said above and I think it makes sense. Except I should have made it \NaiveCotangentComplex but that would have been more work (and we can still do it any time from now into the future).

3. Pingback: Macros | Stacks Project Blog