[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
RE: st: valid invalid syntax
At 03:34 PM 4/22/2004 +0100, Nick wrote:
Richard's comment is interesting.
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.)
> 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.
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.
> 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.
Institute for Policy Studies
Johns Hopkins University
* For searches and help try: