Is this the best way to label the lanthanides using chemnum?

Question

I want to label a series of compounds with the lanthanides, i.e. 10la and I'm using the chemnum package.

The manual gives some hints about this, saying you could do \newcmpdcounterformat{arabic}{\@arabic} but it uses \int_to_<...>. So after some looking around, I found interfaces3.pdf and copy and pasted some code from it, and then got help from the chat when it didn't work. However, I'm a bit worried by the manuals description of the function:

This is the low-level function for conversion of an integer expression into a symbolic form (often letters)

(emphasis mine)

Aren't low level things stuff that people like me are supposed to avoid? Is there a higher level way of doing this? Should I be using a more traditional method of making a list of things, like however \alpha was defined?

Here is the (working) code I came up with:

\documentclass{article}
\usepackage{chemnum}
\RequirePackage{expl3}
\ExplSyntaxOn
\cs_new:Npn \canageek_int_to_lanthanide:n #1
{
    \int_to_symbols:nnn {#1} { 15 }
    {
        { 1 } { La }
        { 2 } { Ce }
        { 3 } { Pr }
        { 4 } { Nd }
        { 5 } { Pm }
        { 6 } { Sm }
        { 7 } { Eu }
        { 8 } { Gd }
        { 9 } { Tb }
        { 10 } { Dy }
        { 11 } { Ho }
        { 12 } { Er }
        { 13 } { Tm }
        { 14 } { Yb }
        { 15 } { Lu }
    }
}
\newcmpdcounterformat{lanthanide}{\canageek_int_to_lanthanide:n}
\ExplSyntaxOff
\labelcmpd[sub-counter-format=lanthanide]{lnwater.la,lnwater.ce,lnwater.pr,lnwater.nd,lnwater.pm,lnwater.sm,lnwater.eu,lnwater.gd,lnwater.tb,lnwater.dy,lnwater.ho,lnwater.er,lnwater.tm,lnwater.yb,lnwater.lu}
\begin{document}
\cmpd{peroxo.meoh} 
\cmpd{DMSOcp}
\cmpd{lnwater.pr}
\cmpd{lnwater.{ce,la}}
\cmpd{lnwater.lu}
\end{document}

Answer 1

You're doing well. The examples in the code of chemnum are

\newcmpdcounterformat {arabic} { \int_to_arabic:n }
\newcmpdcounterformat {alph}   { \int_to_alph:n }
\newcmpdcounterformat {Alph}   { \int_to_Alph:n }
\newcmpdcounterformat {roman}  { \int_to_roman:n }
\newcmpdcounterformat {Roman}  { \int_to_Roman:n }
\newcmpdcounterformat {greek}  { \chemgreek_int_to_greek:n }
\newcmpdcounterformat {Greek}  { \chemgreek_int_to_Greek:n }

from which we deduce that the second argument should be a one-argument (expandable) function that transforms an abstract integer into something else. In the first five cases, a kernel expl3 function exists, for the other two cases something has been devised in chemgreek and, lo, here it is

\cs_new:Npn \chemgreek_int_to_greek:n #1
  {
    \int_to_symbols:nnn {#1} {24}
      {
        {  1 } { \chemgreek_alpha: }
        {  2 } { \chemgreek_beta: }
        {  3 } { \chemgreek_gamma: }
[...]
        { 23 } { \chemgreek_psi: }
        { 24 } { \chemgreek_omega: }
      }
  }

(some lines omitted). So your approach is very good and I see no issue.

The “low-level” you read refers to the fact that \int_to_symbols:nnn is the function actually used for defining \int_to_alph:n and \int_to_Alph:n and could be used for footnote symbols and so on.