Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: RE: RE: FW: RE: RE: Problem with legend option - bug?

From   "Nick Cox" <>
To   <>
Subject   st: RE: RE: RE: FW: RE: RE: Problem with legend option - bug?
Date   Mon, 21 Feb 2005 22:38:57 -0000

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 

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]. 


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:
> [] On Behalf Of Nick Cox
> Sent: Monday, February 21, 2005 2:21 PM
> To:
> 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:

© Copyright 1996–2021 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index