RE: st: valid invalid syntax

[David Kantor <dkantor@jhu.edu>]

At 03:34 PM 4/22/2004 +0100, Nick wrote:
> Richard's comment is interesting.
Richard:

> > if I was
> > writing Stata from scratch, I suspect I would have just made
> > the -if- and
> > -weight- parameters part of the options section of every
> > command; again that seems more natural to me.
I, too have often though that weights could have been part of the options 
-- because they are optional.  One could say the same about -if- and -in-, 
though I hadn't thought of them in that way.  (But compare the -subpop()- 
option in the svy commands.)

On the other hand, weights, as well as -if- and -in-, are common features 
of a great multitude of commands, whereas options are highly variable 
across commands.  I suppose that that is the reason for having them in the 
main section of command syntax.  If we were compelled to put these features 
in as options, then each program that used them would need additional code 
to extract usable information from these features -- perhaps fairly 
complicated code, repeated over hundreds of programs.  (An alternative is 
to have -weight-, -if-, and -in- as reserved option names, which would be 
very undesirable given that no such restrictions yet exist.)

The reason I (and perhaps Richard) thought that these features might as 
well be options, is that they are optional -- and that Stata terminology 
uses "options" to signify the "other" part of the command syntax.

The real purpose of the comma, in addition to what Nick mentioned about 
variable names, is to separate the common core features from the 
customizable and highly variable features.  The latter are known as 
options, and the term is reasonably good.  But it does not accurately 
describe what they are.  The term is succinct if nothing else; more 
accurate terminology would be prohibitively verbose.

Thus, weights, -if-, and -in- are optional central features.  And 
conversely, many commands have "required options" (as distinguished from 
optional options).  So we live with these apparent paradoxes.  But they 
only arise out of the language we use.


Nick wrote:
> What's the history of this design decision? Could
> it have been done his way? Perhaps only
> Bill Gould can say.

Designing a programming language is a blend of practical and aesthetic 
matters. I believe in this case, that the practical issues were the more 
significant. I think that these particular features are successful in that 
they have withstood many years of continuing development.


David Kantor
Institute for Policy Studies
Johns Hopkins University
dkantor@jhu.edu
410-516-5404

*
*   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/