Re: st: bug in bs4rw (or bug in Stata?)

[Nick Cox <njcoxstata@gmail.com>]

Bug I think is too strong a word. We can agree that Stata is not doing
what you expect -- or more precisely want -- but that is a different
story.

Let's work backwards from your own program -snip-. Once you invoke
-snip-, Stata puts anything you typed after the command name into
local macro 0, which here will contain a single comma.

The first statement in your program is a -syntax- statement which says
plainly that nothing is allowed after the command name. Stata then
looks robotically at the contents of local macro 0 to see if it is
consistent with that -syntax- statement, and if it is to assign its
contents to appropriate local macros, which in other examples might be
varlist, if, in, and so forth.

As said, Stata here is working as a rule-based robot taking your own
syntax- statement utterly literally. It proceeds token by token. The
first token is a comma and the only way that Stata knows how to make
sense of that isolated comma is that you are trying to specify
options, which is not allowed by your -syntax- statement, so you are
thrown out.

Now your argument is that Stata should be smart, like a scientist,
statistician, or spouse, to have a good guess within context at what
you really mean even if you say something a bit odd. And we can all
agree that

snip

and

snip ,

mean the same. A comma with no options means the same as no options.
However, Stata does not, at least in this case, look ahead at the next
token to see whether the comma is in fact immaterial. More
fundamentally, -syntax- is not talking semantics, it is talking
syntax.

You have probably experienced the same behaviour when Stata makes a
guess that a period or stop . indicates that you are trying to specify
factor variables or time series operators when it is just a typo for a
comma. It's that robot again. It takes human intelligence to see
instantly "Oh, of course I meant a comma".

As it happens, I don't think it is trivial to specify a syntax in
which you say, "I don't mind a comma there, but no options will follow
it." I think you would need to use -gettoken- rather than -syntax-. I
am confident that it is programmable, but I can't see that I would
ever want to do that, so I am not going to spend any time doing it.

That said, I will happily leave discussion of -bs4rw- to its author,
Jeff Pitblado.

Nick

On Wed, Mar 23, 2011 at 1:49 AM, Keith Dear <keithdear4@gmail.com> wrote:

> -bs4rw- bootstraps a command which may be user-defined. It seems the
> command MUST have options, or at least a syntax statement ending in ",
> *". This seems undesirable.
>
> The following code snippet from bs4rw.ado shows that `cmdname' is
> called with a comma even if `cmdopts' and `rest' are empty.
> If `cmdname' in fact has no options, this causes bs4rw to crash with
> the error message "options not allowed".
> .       capture noisily quietly `noisily' `version'     ///
> .                `cmdname' `cmdargs'                     ///
> .                `wgt' if `touse', `cmdopts' `rest'
> (This is in the code section "bs4rw: First call to `cmdname' with data
> as is" : later on the issue is handled more carefully.)
>
>
>
> But anyway, it seems to me that this should not be a problem, and the
> bug is really in the Stata language, not in bs4rw after all. Consider
> this:
>
> . prog snip
> .    syntax
> . end
> . snip     // no effect of course, but no problems either
> . snip ,   // the comma triggers the "options not allowed" error even
> though no options have been given.
>
> Should this be an error? I don't think so.

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