[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: AW: increment operator

From   Jeph Herrin <[email protected]>
To   [email protected]
Subject   Re: st: AW: increment operator
Date   Fri, 08 Jan 2010 12:48:35 -0500

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

but not

  local C++

may have an intrinsic advantage, but not to any programmer;
it would be historically AND inherently consistent to equate

  local 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. 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:

*   For searches and help try:

© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index