Why is the variable name result treated differently by the Stata 17 table command?

[William Lisowski]

Can anyone explain why the table command under Version 17 should treat the variable name "result" differently than other variable names? Looking at the output of help reswords, I do not see result included among the reserved names.

. about

Stata/SE 17.0 for Mac (Intel 64-bit)
Revision 13 Jul 2021

    ,,,

. codebook result

------------------------------------------------------------------------------------------------
result                                                                       Status in next wave
------------------------------------------------------------------------------------------------

                  Type: Numeric (byte)

                 Range: [0,4]                         Units: 1
         Unique values: 5                         Missing .: 0/387,695

            Tabulation: Freq.  Value
                      367,131  0
                        2,536  1
                          660  2
                        1,307  3
                       16,061  4

. table result

--------------------
Frequency |  387,695
--------------------

. generate foo = result

. table foo

--------------------
        |  Frequency
--------+-----------
foo     |           
  0     |    367,131
  1     |      2,536
  2     |        660
  3     |      1,307
  4     |     16,061
  Total |    387,695
--------------------

.

[Leonardo Guizzetti]

Just a speculation here, but -result- is a tag name for the statistical result being computed (defaulting to counts here).

sysuse auto
table rep78
collect layout
collect layout (rep78) (result)   // same as table rep78

Res.

. collect layout

Collection: Table
      Rows: rep78
   Columns: result
   Table 1: 7 x 1

-------------------------------
                   |  Frequency
-------------------+-----------
Repair record 1978 |           
  1                |          2
  2                |          8
  3                |         30
  4                |         18
  5                |         11
  Total            |         69
-------------------------------

[William Lisowski]

Thank you. That was very helpful.

I see this now (somewhat) in the output of help table.

We start with the basic syntax for one and two-way tables, which suggests a degree of backward compatibility with the earlier version of the command:

   Basic syntax for a one-way table

        table rowvar

        table () colvar


    Basic syntax for a two-way table

        table rowvar colvar

Note that in the above, the arguments to the table command are suggestively titled rowvar and colvar, suggesting variable names rather than keywords. And in the full syntax:

   Full syntax

        table (rowspec) (colspec) [(tabspec)] [if] [in] [weight] [, options]


    rowspec, colspec, and tabspec may be empty or may include variable names or any of the
        following keywords:

          keyword          Description
          --------------------------------------------------------------------------------------
          result           requested statistics
          var              variables from statistic() option
          across           index across() specifications
          colname          column names for matrix statistics
          rowname          row names for matrix statistics
          coleq            column equation names for matrix statistics
          roweq            row equation names for matrix statistics
          command          index option command()
          statcmd          index options statistic() and command()
          --------------------------------------------------------------------------------------

the arguments are rowspec and colspec (as well as tabspec) enclosed in non-optional parentheses, where one of the keywords admitted to rowspec or colspec is "result".

I would argue that either (a) rowvar and colvar in the basic syntax documentation be changed to rowspec and colspec if indeed keywords are allowed, or (b) preferably, in the code for the table command, keywords should only be treated as such when surrounded by parentheses as rowspec and colspec entries.

[Leonardo Guizzetti]

I would support a syntax change here as well. Alternatives would also be to have -table- complain if a variable takes the same name as a keyword, but wrapping one or the other in parentheses could be a straightforward fix.