stan syntax

[Andrew Gelman]

Hey--I just realized that Stan does not allow dots in variable names. Thus, "a.1" is illegal. Is that necessary? If so, that's fine; I was just wondering because I often use dots in my variable names. But maybe that's bad practice on my part, I dunno.
A

[Andrew Gelman]

P.S. It took me awhile to catch this because I didn't get an error in the parsing. I was getting compiliation errs that I didn't understand, I eventually stripped down the model to 1 line, then I suddenly realized the problem.

[Marcus Brubaker]

This is related to C/C++'s prohibition on . in variable names.  It could be worked around, but would be tedious.  Underscores are viable though if you want to use those instead.

In summary (this should be in the manual somewhere and maybe checked in the parser) variable names:
 - Must consist of only letters, numbers and underscores.
 - Cannot begin with a number.

Cheers,
Marcus

[Jiqiang Guo]

And not any one that is reserved by C++, such as friend, private, public, protected, class, ....

--

Jiqiang

[Bob Carpenter]

I hate dots in variable names. R and BUGS are
the only two systems I've ever seen use them.
They're illegal in Java, C++, Python and MATLAB.
What's worse, I'm used to their meaning either
member variable or member function access.

It would be easy to change the syntax to allow them,
but I'd really rather not. I could be convinced to
include them if everyone else thinks they're
important.

- Bob

[Bob Carpenter]

The error message here is tricky because variables
get used in contexts that could also be a function
name or number or bracket.

model {
STATEMENT
...
}

where STATEMENT can be

a_1 ~ foo();
4.2 ~ foo();
(a + b) ~ foo();
{ a ~ foo(); }

So we cna have any of a variable (a_1), a numeric literal (4.2),
a complex expression ((a + b)), or a block ({ ... }). It can
also be just a close curly brace ('}') to end the block.

If I've seen an open brace ('{'), then I have to get a
statement of some kind or a close brace -- I doubt the error
message is that clear, nor do I know offhand how to make it
that clear (I'll think about it some more).

- Bob


On 8/10/12 9:00 AM, Andrew Gelman wrote:

[Andrew Gelman]

I am fine with not allowing dots.
A

[Bob Carpenter]

On 8/10/12 11:25 AM, Marcus Brubaker wrote:
> This is related to C/C++'s prohibition on . in variable names. It could be worked around, but would be tedious.
> Underscores are viable though if you want to use those instead.
>
> In summary (this should be in the manual somewhere and maybe checked in the parser) variable names:
> - Must consist of only letters, numbers and underscores.
> - Cannot begin with a number.

That is in the manual in the programming language description
part in the secton on variable names.

The error warnings are difficult for the reason I pointed out
before, but I'll try to make them clearer.

- Bob

[Bob Carpenter]

Good catch. I'll add the C++ reserved words
to the doc and check that they're not used in
the parser.

We might also want to impose a size limit for
portability? I don't know what the issues are
with modern C++ compilers.

- Bob

On 8/10/12 11:28 AM, Jiqiang Guo wrote:
> And not any one that is reserved by C++, such as friend, private, public, protected, class, ....
>
> --
> Jiqiang
>