[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
RE: st: valid invalid syntax
Richard's comment is interesting. What's
the history of this design decision? Could
it have been done his way? Perhaps only
Bill Gould can say.
There are at least three points of
view here, that of the Stata user, the
Stata programmer and the Stata developer.
(Programmers write Stata programs; developers
(exclusively at StataCorp) write the executable,
design the language, and write Stata programs.)
Users have to accept the syntax as given,
and in fact programmers have only a little
As far as programmers are concerned, their main
concern is with the -syntax- statement at the
head of most programs they write. How
Stata sorts out the syntax elements from a
command line is way beyond programmers'
comprehension, as it is hidden in the executable,
and the concern of the developers.
Perhaps the main single point of the comma,
so to speak, is to distinguish between variable
names and option names. That should be clear.
Without some distinction, chaos would ensue,
as users would have to ensure that their
variable names were never confusible with
option names, and programmers would also
get blamed for any such problem! The
comma of course is not the only way to
do this. Perl, for example, shows a very
if ... and in ... are distinguished from
variable names because -if- and -in-
are reserved words.
Weights are distinguished by their
But could they have been put after
I surmise that the choice made was not driven
by syntax. It was, literally, a design choice.
The idea was to make selections -if- and -in-
and the use of weights seem central to the
language. As said, that's a guess.
> 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.
* For searches and help try: