William Dupont
> Nick
>
> First, I'm not really arguing. Just stating preferences that
> I believe
> would make the software easier to use. Second, I don't claim to know
> "what is going on under the hood" or what improvements to
> Stata are easy
> or hard to implement. The ideal solution would be to make the legend
> option work regardless of whether -legend- is or is not nested.
> Intuitively, I would have thought that providing error or warning
> messages would be easier than changing the syntax -- perhaps I am
> wrong.
I think you are correct insofar as tweaking a program is generally
easier than rewriting it. But by definition error messages are issued
only when the syntax is incorrect, or something is impossible,
or contradictory demands have been made, etc., none of which seem to
apply here. What you seem to want is that StataCorp add warning messages
when users make requests that the programmer thinks is unlikely
to be what they really want. I wouldn't rule that out in principle,
but I've not heard a convincing example in this thread.
> With respect to disabling confusing or rarely used syntax I
> believe you
> do misunderstand me. What I am suggesting is the disabling of syntax
> that the parser ignores. I would think it unlikely that anyone would
> wish to use an option that was ignored. Perhaps there are programming
> examples where you would want to do this, in which case a warning
> message would be preferable to a true error message. Either way, this
> would not prevent people from using infrequently used commands.
I don't think that there is any syntax that the parser ignores.
In the example of -graph- there is an issue of when it is
scrutinised closely, as syntax is examined at various
different levels, as programs call other programs, and so
on, and so forth.
It is true that programs can be written to ignore choices
that the user makes. Perhaps this is going on here. To
give two tiny examples that illustrate the point:
A few -egen- functions create string variables. -egen- allows
the user to specify the type of variable created. It is often
a good idea to ignore what the user types and let the program
optimise the variable type. This is a feature if the user
specifies something like -double- or -str41- but the problem
needs -str42-.
Some graphs depend delicately on a particular -sort- order,
yet a wildcard set of options might let pass a -sort- through
indulgently, which then messes up the -sort- order when
the graph is drawn. A programming
solution is to allow -sort- explicitly as a user option but
then ignore it.
These are indeed examples in which programmers suppose that they
know better what the user really wants, so seem loosely in
the spirit of what Bill is suggesting.
> Of course it is true that it is very difficult to know what the user
> really wants. It is probably safe to assume, however, that
> she/he wants
> something. Hence, any time the user enters syntax that is
> ignored it is
> very likely that he/she has done something wrong. Also, the debugging
> of any program is always more difficult if the parser is allowed to
> ignore text that it does not understand.
>
> In your first email in this thread you seemed to imply that the Stata
> parser did not act as an advice or counseling facility. There is,
> however, at least one example where it does play this role. If you
> issue an -stset- command with the -id()- option, the parser
> will give a
> -PROBABLE ERROR- message if it thinks that you have messed up. I have
> often found this feature to be very helpful in correcting the
> errors of
> my way.
Sure, but this is not the parser speaking. It is the result of
a higher-level bit of interpreted code added ad hoc. Naturally, what one
calls it is secondary; and it is indeed very helpful.
Neither of us is a Stata developer -- someone at StataCorp with access
to the internal details of the executable -- but the parser, as I
understand it, is not a synonym for all the code that takes a
Stata command and looks at it. So I am using the term in a narrower
sense than you are, but one that is intended to be consistent with
StataCorp.
> I do agree that documentation is key and have found Mitchell's book to
> be very helpful. The online documentation on the -legend- and -by-
> options could be easier to find. In my case, I only
> discovered it after
> doing a search of the Statalist archives, which led to David
> Harrison's helpful email.
The optimum manual has to be written by the user once they have
discovered what they most want and how to do it!
Nick Cox
> We may be arguing at cross-purposes here. Let
> me try to make myself clearer.
>
> Naturally I agree that Stata's syntax is pretty complicated
> here and that
> understanding the syntax oneself (everyone's problem)
> explaining that to others (many people's problem)
> are important issues.
>
> But my sense is that what Bill wants, even if judged a desirable
> tweak to the software, is about an order or two more
> difficult to program
> in a consistent way
> and without undesirable side-effects
> than he seems to be guessing. This is because the
> problem touches on what the user is thought
> to want, which is not a question of syntax at all.
>
> But desirability in principle is the first thing
> to discuss.
>
> I sense steps towards two alarming principles here --
>
> if some users get mighty confused by some syntax,
> then that syntax should be disabled.
>
> if some syntax is rarely used,
> then that syntax should be disabled.
>
> There are two big empirical questions here, and who
> is going to collect the data, but more crucially
> that's pretty tough on the people who understand
> that syntax or people who want to use the rarely
> used syntax, either rarely or even frequently.
>
> I must be misunderstanding, because I can't believe
> that I am hearing these ideas.
>
> What I can support is people writing wrapper graphics
> programs that give simplified interfaces to -graph-,
> in effect using a different syntax, and some of my
> own programs come into that category. It's quite
> difficult to do that without making desirable things
> impossible. That is, the programmer provides a simplified
> way to get certain kinds of graph, but has to try to
> keep open the scope for users to modify something else
> not directly controlled by their program.
>
> Similarly, some one could write a -byplot- (or whatever)
> with wired-in defaults for what is (supposedly) rarely
> used and tweakable options for what is often wanted
> to tweak. That would be a far easier solution than StataCorp being
> advised to cut functionality because of these
> principles. (More important than my incredulity here is
> that I can't see StataCorp buying these principles.)
> There is no need for brilliant ideas here: you just
> hard-wire option choices you find yourself making
> repeatedly.
>
> To put it another way, I assert that if there is a solution to
> this confusion it comes mostly at the level of
> add-ons, or indeed at the documentation level. Michael
> Mitchell's book is a striking illustration of a how
> a different format explains many things that some readers
> fail to find, or fail to understand, in [G].
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
