'Missing number, treated as zero.' error with \newcount and xparse - TeX

TopAnswers TeX

Top Answer

Phelype Oleinik

`\mycount` is not expandable (because it uses `\regex_count:nnN`), so it can't appear in `\numexpr`.  When `\numexpr` starts, it is looking for a number, but then the first thing it sees is an unexpandable token, so it complains `Missing number, treated as zero`, which is exactly what happened: a number is missing for `\numexpr`, so it was treated as zero (thus `\foo` is zero).  Then the rest of the macro executes normally.

You need an expandable method to count the number of `a`, or first do the counting, then assign to `\foo`.

Here's a changed `\mycount` function that accepts a trailing optional argument, which should be a count register.  If the argument is provided, the count is assigned to that register, otherwise the count is typeset.

```
\documentclass{article}
\usepackage{xparse}
%% Courtesy: https://tex.stackexchange.com/a/525246
\ExplSyntaxOn
\int_new:N \l__lng_tmpa_int
\NewDocumentCommand \mycount { s m m o }
  {
    \IfBooleanTF {#1}
      { \lng_count:nVn {#2}  #3  {#4} }
      { \lng_count:nnn {#2} {#3} {#4} }
  }
\cs_new_protected:Nn \lng_count:nnn
  {
    \regex_count:nnN {#1} {#2} \l__lng_tmpa_int
    \IfValueTF {#3}
      { \int_set_eq:NN #3 \l__lng_tmpa_int }
      { \int_to_arabic:n { \l__lng_tmpa_int } }
  }
\cs_generate_variant:Nn \lng_count:nn { nV }
\ExplSyntaxOff

\newcount\foo
\NewDocumentCommand{ \mycnt }{ u{):} }{%
  \mycount{a}{#1}[\foo]
  \the\foo: #1%
}

\begin{document}
\mycnt aaaabccca ):
\end{document}
```

One thing that wasn't said here, AFAIK: the reason why `\int_set_eq:NN #3 \l__lng_tmpa_int` is correct (or rather: *currently works*) when `#3` is a `\countdef` token (which is the case for `\foo` in the question and in Phelype's answer) is because **`expl3` `int ` variables are `\countdef` tokens** (i.e., named `\count` registers). See *Creating and initialising integers* in [source3.pdf](http://mirrors.ctan.org/macros/latex/contrib/l3kernel/source3.pdf), or [l3int.dtx](https://github.com/latex3/latex3/blob/main/l3kernel/l3int.dtx): ``` \cs_new_protected:Npn \int_new:N #1 { \__kernel_chk_if_free_cs:N #1 \cs:w newcount \cs_end: #1 } ... \cs_new_protected:Npn \int_set_eq:NN #1#2 { #1 = #2 } ``` As you can guess, `\cs:w newcount \cs_end:` is just the `expl3` way of expressing `\csname newcount \endcsname`. source3.pdf explains that this indirect way is used instead of simply `\newcount` so as to allow `\int_new:N` to be used in non-top-level contexts (like inside a macro definition... for very special needs!). This would fail with `\newcount` because it is defined as `\outer` by TeX. If you've understood the above and basic things from the TeXbook on `\count` registers, you won't be surprised by this definition either: ``` \cs_new_eq:NN \int_use:N \tex_the:D ``` which means that `\int_use:N` is just a fancy name for `\the`. :-)

As with other parts of this argument, there is nothing _particularly_ wrong with using `\NewDocumentCommand` for internals, but it's not a good practice in general. Starts with the semantics: you're defining a `\NewDocumentCommand`, not a `\NewInternalMacro` ;). Then, commands defined with `\NewDocumentCommand` have some overhead for argument parsing, and if you use them for several internal macros it adds up and make your code unnecessarily slower. Finally, internal macros shouldn't really have optional arguments, so you end up not using most of `xparse`'s functionality. Then, if you have an internal macro defined with `\NewDocumentCommand \foo:nnnnn { mmmmm } {...}` it's trivial to replace by `\cs_new_protected:Npn \foo:nnnnn #1#2#3#4#5 {...}` or even `\cs_new_protected:Nn \foo:nnnnn {...}`.

> But for internal macros you won’t use `\NewDocumentCommand`, but instead `\def` or `\cs_new(_protected):Npn` The macro I am defining right now is public, so I will have to use `u`, but in general I am curious to know why shouldn't I use `xparse` commands for internal functions? I almost don't know any `latex3` syntax, hence I tend to avoid using it and I find `xparse`-variants easy to understand than the `\def` and friends. So I in fact have some internal commands which I have defined with `\NewDocumentCommand`. I have taken the general precaution of adding the `pkg@` prefix to the internal cs-name to make them inaccessible for the general public. Isn't that enough?

Thanks, I guessed it right then. I will surely avoid this syntax in my work, but right now I am trying to reimplement an old package with some new functionalities and hence unfortunately for backward compatibility I will have to use this argument type.

On the programmer's side, there's not a hard-set rule. If your code requires a macro delimited by `):`, then there's not much you can do. But for internal macros you won't use `\NewDocumentCommand`, but instead `\def` or `\cs_new(_protected):Npn`, so you will not use the `u` type anyway.

`\NewDocumentCommand\foo{u{):}}{}` is essentially the same as `\def\foo#1):{}`, so the criticism applies to both. However, `\NewDocumentCommand` is supposed to define Document Commands™, that is, user-level commands, and users are familiar with syntax like `\foo*[opt]{arg}`, but not `\foo arg ): * {opt} &arg&` (both easily doable with `xparse`), so it is best practice to stick to the well known, easy to remember syntax, than creating a new weird one that ppeople will struggle to remember.

Thanks. Just to clarify, when you say that it provides an unusual syntax, do you mean the syntax on the users' side or on the programmers' side? So if `\mycnt abcd ):` is itself unusual according to you; then `\def\mycnt#1):` and `\NewDocumentCommand{\mycnt}{ u{):} }` both will be equally problematic, right? If that's what you are trying to say, then I get your point, but if the "unusual syntax" is from the programmers' point of view, then I don't understand why `\def\foo#1):` is usual and the `xparse` variant isn't.

`u` is not in the kernel because we've marked it as deprecated: packages that used `u` will still work loading `xparse` (it won't be completely removed), but newer code that wants to build on kernel functionality should not use that

Yes, `u` _is_ `\def\foo#1):`. The problem with it is not how it works (it works the same as the plain TeX version with `\def`, and in case the end delimiter is not found, both throw the same low-level TeX error). The issue with `u` (and `G` and `l`) is that they provide an “unusual” syntax, which then ends up making documentation and user interfaces stranger. Joseph wrote [this blog post](https://www.texdev.net/2020/08/19/the-good-the-bad-and-the-ugly-creating-document-commands) on these argument types.

The `__` is there to denote a private variable. If it were `\l_lng_tmpa_int` then it would be public, and it would need documentation. Since it's a temporary variable, it probably shouldn't be public/documented.

I have been warned regarding this on another thread too. The alternate syntax I got was `\def\foo#1):`, but my question was is there any performance-related difference between this syntax and the `xparse` one? I understand that this type of syntax is not supported directly in the kernel and one has to explicitly load the package for it, but other than this is there any other problem with this argument-type?

@निरंजन `\mycount` is not expandable (because it uses `\regex_count:nnN`), so it can't appear in `\numexpr`. You need an expandable method to count the number of `a`, or first do the counting, then assign to `\foo`.

Please see [this](https://tex.stackexchange.com/a/525246) answer used in my question. I can't do something like `\countin{[aeiou]}{This is a test}` with `xstring` commands, right? Also @Skillmon once had removed that package from one of my code for boosting the performance. So I tend to avoid it.

1 Answer