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].
Nick
[email protected]
Dupont, William
> My understanding from reading David's email and the Stata
> documentation
> is that nesting the -legend- option within the -by- option is
> necessary
> (or at least highly desirable) for programming reasons. It does not,
> however, make for the easiest syntax from the user's perspective. My
> suggestion of a warning message was based on the assumption that this
> would be the easiest way for Stata to help users from getting stuck
> without requiring a lot or reprogramming on Stata's part.
>
> Your delineation of the parser's job is fine. If for
> esthetic or other
> reasons it is deemed desirable to limit its role to these four areas
> then I for one would prefer to outlaw the use of options or suboptions
> that will be ignored. For example, suppose I want scatter plots of y
> and z against x for separate values of a classification
> variable t. If
> I want this graph to have a legend of a single column in the
> upper left
> hand corner of the graph I must issue a command like
>
> . scatter y z x , legend(col(1)) by(t, legend(position(11)))
>
> The -col- option must be in the unnested -legend- option and the
> -position- option must be in the nested -legend- option.
>
> . scatter y z x , legend(col(1) position(11)) by(t)
>
> ignores the -position- option while
>
> . scatter y z x , by(t,legend( position(11) col(1)))
>
> ignores the -col- option. The Stata parser often gives helpful hints
> when I make an error. If it is too hard to simplify the
> syntax, then it
> would be more user-friendly to forbid suboptions in locations
> where they
> will be ignored and give an indication as to where these suboption
> should be placed. Doing this would not violate your definition of the
> parser's role.
>
> The preceding examples are all rather obscure. However, the
> unexpected
> response to a command similar to
>
> . scatter y z x , legend(off) by(t)
>
> is one that I stumbled across in a real example. I personally would
> have prefer this command to generate syntax error directing me to nest
> my -legend- in my -by- option. I found the current behavior of just
> ignoring the -legend- option to be confusing.
>
> Bill
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Nick Cox
> Sent: Monday, February 21, 2005 2:21 PM
> To: [email protected]
> Subject: st: RE: FW: RE: RE: Problem with legend option - bug?
>
>
> This area of syntax is certainly
> troublesome while you are learning it,
> but I am not sure what Bill wants here.
>
> The parser has, as I understand it,
> one essential job with four components:
>
> 1 parse what the user types into tokens
>
> 2 decide if the whole is legal
>
> 3 issue an error message if not
>
> 4 pass on for execution if so.
>
> What facilities are you requesting for
> the parser here? Some sort of advice
> or counselling facility?
>
> "Are you sure that you really mean to
> ask for that?"
>
> That goes way, way beyond what is the
> scope of the parser, in terms of either
> aim or ability. I can't see it as a
> job for any other part of the software
> either.
*
* 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/
