We can't see grins easily on Statalist.
On your question: No, there's a difference.
`C++' is not something anyone would have written on purpose before Stata
introduced the ++ operator. I don't have a copy of Stata old enough to
test whether it would have been illegal or just something that evaluated
to empty. But allowing it breaks no working code and no principle.
That's not true of
local C++
as I explained.
I should stress that my previous was just my interpretation of why
StataCorp disallow this; I've seen no official comment.
Nick
[email protected]
Jeph Herrin
More humor than harshness intended, but it would not be the
first time my wit missed its mark.
I'm not so concerned with how Stata behaves compared with
another language, as with how Stata behaves compared with
itself. A syntax that equates
local ++C
`++C'
but not
local C++
`C++'
may have an intrinsic advantage, but not to any programmer;
it would be historically AND inherently consistent to equate
local C++
`C++'
would it not? If anything, I am implying that StataCorp
have defined the second term to match their existing definition
of the first.
Nick Cox wrote:
> I think that is a little harsh.
>
> Most of us have never even tried to design a language, but a little
> thought lets one identify a variety of general and specific facts that
> probably led to this (deliberate) syntax decision.
>
> First off, the language we are talking about is Stata and like most
> languages it is eclectic with conscious borrowings from various other
> languages (and plenty of its own ideas). Borrowing some syntax element
> does not commit Stata to total borrowing of what comes bundled with it
> in any original language. For a start, some features in any language
may
> seem like very good ideas and others not so good. That is why
designers
> tend to be eclectic in the first place.
>
> Here many people will recognise ++ and -- as operators in C and
several
> other languages. That recognition, I guess, leads Jeph and others to
> expect those operators to be implemented in Stata in exactly the way
> programmers know in other languages. I'll focus here on ++ but the
issue
> is not different with --.
>
> But a key principle -- and one that bites very hard in practice -- is
> that any new syntax elements must be compatible with the rest of
Stata.
>
> In this case Stata decided long ago that "+" could not be part of a
> name. So before Stata introduced ++ as a operator Stata tokenized
>
> local c+
>
> as a command -local-, a name -c- and text "+" with the effect that the
> local macro -c- was set to contain "+" as its contents. Similarly with
>
> local c++
>
> and "++" as its contents. Note here, however surprising it may be,
that
> Stata does not insist on a space separator between name and contents.
>
> Jeph appears to be implying that StataCorp should have changed the
> meaning of
>
> local c++
>
> to be what he wants. There is a case for that, but StataCorp decided
> that it was easier to continue with the previous interpretation.
>
> Quite a bit more could be said, but I'll restrict myself to one
further
> comment. Note that we can't seriously entertain an argument that Stata
> programmers almost certainly mean what Jeph meant when they write
>
> local c++
>
> as it's essential that _syntax_ be quite independent of meaning.
> Otherwise put, a language in which it is presumed what the text "++"
> `means' is one in which syntax rules are messed up with semantic
> considerations.
Jeph Herrin
> So, intentionally bad behaviour.
>
> Martin Weiss wrote:
>
>> " Seems like a bug."
>>
>> But note [U], p. 209:
>>
>> " Finally,
>>
>> local i++
>>
>> will not increment the local macro i but instead redefines the local
> macro i
>> to contain ++."
>
> Jeph Herrin
>
>> Is the behaviour of the following to be expected?
>>
>>
>> local C = 0
>> forv i=1/10 {
>> di "`C'"
>> local C++
>> }
>>
>> I know the increment operator is ++C, but inadvertently used this
>> instead and could not track down the error for quite a while, because
>> it even produced integer values in places. Seems like a bug.
>> Especially as trailing ++ is allowed in expansion operators:
>>
>> local C=0
>> forv i=1/10 {
>> di "`C++'"
>> }
>>
>> works just fine.
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
