Re: st: -confirm variable- does not accept varlist (wildcards)

[Nick Cox <njcoxstata@gmail.com>]

This is well argued, but it is possible to pick at the details.

confirm new variable m*

has an interpretation: is it the case that any name beginning with "m"
would be acceptable as a new variable name? (The answer would be no if
any variable already had such a name.) But it is difficult to see this
as a question one might to ask in a program. Interactively, one would
be likely to -describe m*- and note the absence.

confirm variable m*

is, with appropriate modifications to the argument, also a question
that makes sense, but not one that I would want to ask (at least using
-confirm-).

We are in the territory between meaningless in principle and pointless
in practice; I think we are a little nearer the second than Robert is
arguing.
Nick
njcoxstata@gmail.com


On 6 September 2013 14:41, Robert Picard <picard@netbox.com> wrote:
> I agree that the help on -confirm- is a bit unclear. However, the
> following is at the very top of the help file:
>
> "confirm verifies that the arguments following confirm ... are of the
> claimed type and issues the appropriate error message and nonzero
> return code if they are not."
>
> The word "type" here does not mean storage type (i.e. string or
> numeric). It applies to file, matrix, scalar, as well as variable.
> Thus -confirm variable- checks that what's in varlist are variables.
> Using wildcards to confirm a new varlist makes no sense (e.g. -confirm
> new variable m*-). The same is true when checking for the existence of
> variables (e.g. confirm variable m*). Adding a specific type just adds
> an additional condition to check.
>
> On Fri, Sep 6, 2013 at 4:39 AM, Nick Cox <njcoxstata@gmail.com> wrote:
>> I agree with Maarten's stance here, but (away from -confirm-) there
>> are situations in which temporary variables can be wildcarded.
>>
>> Some commands require a stub to be specified and then they -generate-
>> (or generate) new variables <stub>1, <stub>2, and so forth. -separate-
>> and -tabulate- are examples.
>>
>> If you need these new variables within a program, and only
>> temporarily, then a natural device is something like
>>
>> tempname foo
>> separate myvar, ... gen(`foo')
>>
>> I often do this within graphics programs. How are subsets to be
>> represented differently? By putting them in different (and new)
>> variables.
>>
>> In this case -separate- returns r(varlist) but a wildcard `foo'* would
>> also work as a temporary name will be just 8 characters long
>> underneath the hood, and will be something like __000007 with a
>> licence to hold data. So the variables will be created as __0000071,
>> __0000072, and so forth.
>>
>> This is living a little dangerously, as I believe that StataCorp have
>> _nowhere_ promised that the real names underlying temporary names will
>> remain 8 characters long. In fact, I doubt that they want to promise
>> anything except that temporary names will remain temporary. Should
>> StataCorp ever make temporary names as long as the maximum name length
>> allowed, then adding suffixes like this will no longer work (although
>> it would be nice if it were protected by version control).
>>
>> Nick
>> njcoxstata@gmail.com
>>
>>
>> On 6 September 2013 08:37, Maarten Buis <maartenlbuis@gmail.com> wrote:
>>> On Thu, Sep 5, 2013 at 5:29 PM, Joe Canner wrote:
>>>> I'm intrigued by your last sentence in #2.  Are you've saying you've never had occasion to use wildcards in varlists, or that there are alternatives?  For example, suppose you wanted to do something with all system-generated variables _*, knowing that these might be scattered around the dataset and not contiguous.  How would you do that without wildcards?
>>>
>>> Nick, already stated that he did not use wildcards in combination with
>>> -confirm-. Let me speculate why that is the case. When programming you
>>> typically allow varlist including wildcards to be specified by the
>>> user, but that input is parsed at the very beginning by the -syntax-
>>> command. One of the things that the -syntax- command does is that it
>>> unabreviates varlist and passes that on to a local macro that the
>>> programmer uses in the rest of the program. So, after the -syntax-
>>> command there are no longer any wildcards in the user input. It may
>>> happen that the program creates (temporary) variables. There again I
>>> would never use wildcards to refer to those variables, because it may
>>> happen that there are already variables in the dataset that conform to
>>> that pattern with wildcards, and thus break your program. Typically,
>>> you create the variables and store their names in a local macro and
>>> refer to that local macro further on in the program. So when
>>> programming in Stata wildcards almost never appear after the -syntax-
>>> command, which is usually one of the very first commands inside a
>>> program.
>>>
>>>> You said " I am not sure how confirm *should* work with wildcards".  According to the -confirm- documentation, not only should -confirm var- work with a varlist, but they even give an example of using it with multiple variables.
>>>
>>> An example with multiple variables does not indicate whether or not
>>> wildcards should be allowed. What is relevant is the statement in the
>>> helpfile that it refers to a varlist, and it provides a link to the
>>> help-file that defines what a varlist means in Stata: -help varlist-.
>>> This definition includes wildcards. So it sounds to me that the
>>> helpfile is somewhat unclear about this point and the error message
>>> could be improved.
>>>
>>
>> *
>> *   For searches and help try:
>> *   http://www.stata.com/help.cgi?search
>> *   http://www.stata.com/support/faqs/resources/statalist-faq/
>> *   http://www.ats.ucla.edu/stat/stata
>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/faqs/resources/statalist-faq/
> *   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/