Patrick,
Quite right. I did not intend to suggest that varname abbreviations couldn't
burn you accidentally. Quite the opposite. Indeed, particularly because I
never use, and hence do not rely on, varname abbreviations, I would
certainly be in favour of a -set-able option to disable them. My "in favour"
response to Nick's straw poll, however, comes with the qualification that I
don't plan to picket StataCorp's College Station office (campus for
semi-reformed academics?) if I don't get it. :-) <--- note: smiley face
means I'm joking
Lee Sieswerda
> -----Original Message-----
> From: [email protected] [SMTP:[email protected]]
> Sent: Tuesday, February 11, 2003 4:13 PM
> To: [email protected]
> Subject: st: RE: RE: RE: RE: Referring to a varname, leading to
> errors
>
> Nick wrote
> > But let's pose a question to Stata Corp and one to users.
> >
> > 1. Stata Corp
> > =============
> >
> > Suppose a user like Glen doesn't want to be bitten
> > ever by this. Imagine that such users can
> >
> > . set literalvarnames on
> >
> > meaning
> >
> > "Listen here, Stata: you are to behave, given my
> > input, as if you never allowed abbreviated variable names."
>
> ... something akin to pragmatic modules in Perl, i.e. a way to instruct
> Stata how we'd like it to behave. Even Stata's version control facilities
> can be viewed as such (right?), so perhaps it might not be that difficult
> to
> implement.
>
>
> >
> > How easy would that be? Would there be side-effects?
> > Well written programs that Glen uses, consciously
> > or not, should all make use of temporary variables,
> > but in practice there may be exceptions.
> >
> > In practice, perhaps, the issue is Command window input PLUS .do
> > files.
> >
> > 2. Users
> > ========
> >
> > Do you want what Glen wants? Not disallowing all
> > variable name abbreviations, which I guess will
> > never happen, but being able to set this for yourself
> > to avoid what Glen describes.
> >
> > Nick
> > [email protected]
> >
>
> To which Lee Sieswerda replied
> > I, for one, never use varname abbreviations. Perhaps in some deep
> > recess of my psyche I believe in Murphy's Law and don't want to run
> > into Glen's problem inadvertantly.
>
>
> Abbreviations can hurt you even if you don't ever use them, such as
>
> i) dropping a variable you never intended to drop; or
>
> ii) inadvertently modifying the wrong variable
>
> For e.g., at some point in time your data contains variables _foo_ and
> _foobar_. You no longer need _foo_ so you -drop- it. Later, (wrongly)
> believing _foo_ is still defined, you -replace foo = ...- but it modifies
> -foobar- instead since Stata finds no ambiguity in the string literal
> _foo_.
> You might never notice this blunder. Dealing with large datasets at
> times,
> with hundred of variables possessing names that differ by only a character
> or two, this can have unfortunate consequences. I almost never use
> abbreviations myself either and typically, when I want to modify _foo_, it
> is _foo_ I want to change and certainly *not* _foobar_.
>
> Granted, if nothing can be done to let users specify Stata's behaviour via
> a
> pragmatic command, some cost-benefit analysis must be made to weigh user
> convenience vs. safety-features. And if that's the case, then I can live
> with it. But if the sole explanation for this behaviour is rooted in
> history (of Stata's development that is), then it becomes increasingly
> difficult to buy into the cost-benefit justification. To have the option
> of
> turning off all abbreviations would be a monumental safety improvement
> IMHO.
>
>
> Patrick Joly
> [email protected]
> [email protected]
> *
> * 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/
*
* 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/
