[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: RE: Stata functions
I suspect that this was decided as the
convention a long time ago and Stata
has stuck to it since.
There is at least one very good reason, however.
You are thinking of functions for which the
arguments in practice are always lists of variables, but
syntactically there is nothing to stop you typing
other stuff, say,
missing(exp(1), _pi, 42)
and in a program one might well calculate
where the macro evaluates to a number not known
in advance. Now once expressions evaluating to
numbers are allowed, in particular, the problem
is what is meant by
Stata's other rules would treat
4 - 7
as an expression to be evaluated on the fly,
namely to -3. Insisting on
fixes this problem.
In short, allowing lists without comma separators would solve one
problem at the expense of creating another.
Of course, you may well say that you want both syntaxes! That
in turn would be understandable, but objectionable on yet other
-missing()- is in practice fairly extreme in that most applications
probably involve variables. (And -egen- offers functions too.)
With other functions this would arise all the time and often bite
users: in fact, any time that a negative number was not first in the list.
What's more, this would be badly hidden as it could well happen
in some observations and not others.
If this arises often a little utility is programmable to
put the commas in. In fact one such is lurking in your folders.
> Apropos of the recent discussion of inlist, I have often
> wondered why Stata
> doesn't allow varlists in functions, but instead requires
> comma separated
> lists. For example,
> missing(,a,b,c,d,...) is required. Why not a varlist? I can't
> quite see any
> difference. However, in terms of programming, a varlist is
> much easier.
> reg y a b c if !min(b_*)
> is much easier than typing each of the 10 b_ variables which
> may be long
> and easy to misspell.
* For searches and help try: