Feature request: disallow ++

[ksvanhorn]

I had some Stan code that had the lines

idx <- 0;
shparms[++idx] <- logit_lambda;

thinking that I was using the pre-increment operator on idx. Instead, it appears that "++idx" was interpreted as +(+idx), i.e., just idx. This is correct according to the published syntax reference, but unexpected. I suggest that "++" should be parsed as one token and, as long as pre-increment isn't supported, should give an error.

[bob-carpenter]

Good point. This is very confusing. And it'll probably
also crop up with x-- + x, which I'm guessing would get parsed as
(x - (-+x)) == (x + x).

I see four options

• add ++x and --x to Stan's language with the usual semantics
• trap uses of ++x, --x, x++, x-- and print warnings
• trap uses and raise an error
• just get rid of (+x) as it's useless from within Stan itself
  (and frankly, also pretty useless within C++ itself, but we
  want to leave it there so all C++ programs work as expected).

Does anyone else have an opinion? And if we go with the first option,
do we also add post increment,

• add x++ and x-- to the language
• Bob

On Mar 14, 2015, at 5:04 AM, Kevin S. Van Horn notifications@github.com wrote:

I had some Stan code that had the lines

idx <- 0;
shparms[++idx] <- logit_lambda;

thinking that I was using the pre-increment operator on idx. Instead, it appears that "++idx" was interpreted as +(+idx), i.e., just idx. This is correct according to the published syntax reference, but unexpected. I suggest that "++" should be parsed as one token and, as long as pre-increment isn't supported, should give an error.

—
Reply to this email directly or view it on GitHub.

[syclik]

Would it be possible to only allow x++ and ++x for ints only?

If so, I would vote including ++ for ints and option 3, trap and raise an
error.

If not, then option 1. I'd also want a += type operator, but not sure what
that would look like. <+ looks weird to me, but I also had to get used to
<-.

On Friday, March 13, 2015, Bob Carpenter notifications@github.com wrote:

Good point. This is very confusing. And it'll probably
also crop up with x-- + x, which I'm guessing would get parsed as
(x - (-+x)) == (x + x).

I see four options

• add ++x and --x to Stan's language with the usual semantics
• trap uses of ++x, --x, x++, x-- and print warnings
• trap uses and raise an error
• just get rid of (+x) as it's useless from within Stan itself
  (and frankly, also pretty useless within C++ itself, but we
  want to leave it there so all C++ programs work as expected).

Does anyone else have an opinion? And if we go with the first option,
do we also add post increment,

• add x++ and x-- to the language
• Bob

On Mar 14, 2015, at 5:04 AM, Kevin S. Van Horn <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

I had some Stan code that had the lines

idx <- 0;
shparms[++idx] <- logit_lambda;

thinking that I was using the pre-increment operator on idx. Instead, it
appears that "++idx" was interpreted as +(+idx), i.e., just idx. This is
correct according to the published syntax reference, but unexpected. I
suggest that "++" should be parsed as one token and, as long as
pre-increment isn't supported, should give an error.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#1365 (comment).

[rok-cesnovar]

Stanc3 errors with:

Syntax error in 'examples/bugs/test_model.stan', line 3, column 4 to column 5, parsing error:

 1:  transformed data {
 2:    int a = 0;
 3:    a++;
          ^
 4:  }

---

Ill-formed expression. Expect an expression after "+".

So closing.