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

RE: st: valid invalid syntax


From   David Kantor <dkantor@jhu.edu>
To   statalist@hsphsun2.harvard.edu
Subject   RE: st: valid invalid syntax
Date   Thu, 22 Apr 2004 12:52:17 -0400

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/




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