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.
Nick
[email protected]
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/
