-
-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse error in if-else #2697
Comments
Yes, this should parse. Would you mind labeling these things with a deliverable (bugs should be next release) and an assignee (@mitzimorris is handling all the current bugs for the parser while @VMatthijs and @seantalts work on the Stan 3 parser). |
Great! I already have all of these bugs I'm submitting fixed in the Stan 3 compiler. I am just submitting them to make sure that people agree they are bugs before I change the existing behaviour. I don't think it's worth anyone (@mitzimorris ) spending time on fixing them in the existing compiler. The new compiler should be finished in not too long. My sense is that for the moment, there are better things to spend time on than the old compiler. |
On Nov 18, 2018, at 3:53 PM, Matthijs Vákár ***@***.***> wrote:
Great! I already have all of these bugs I'm submitting fixed in the Stan 3 compiler. I am just submitting them to make sure that people agree they are bugs before I change the existing behaviour.
Do you still plan to try to write a spec?
I don't think it's worth anyone spending time on fixing them in the existing compiler. The new compiler should be finished in not too long.
What's "not too long"? Do you have an expected time of completion for when it'll be ready to go out in a release in CmdStan, RStan, and PyStan?
My sense is that for the moment, there are better things to spend time on than the old compiler.
I believe bug fixes for our current releases need to remain a top priority until we have a viable replacement.
|
If you think it's worth writing out a spec, then I'm happy to write a document outlining what's implemented, though I'm hopeful that the implementation itself is rather readable as well, as almost all of it is written in a declarative style. My expected timeline is as follows:
That would get us to the point of a complete beta version of the compiler around Christmas. Are you still not convinced the new compiler will be done soon enough that we can pause bug fixes on the language for now and concentrate on the Math library and interfaces until then? |
On Nov 18, 2018, at 7:16 PM, Matthijs Vákár ***@***.***> wrote:
If you think it's worth writing out a spec, then I'm happy to write a document outlining what's implemented, though I'm hopeful that the implementation itself is rather readable as well, as almost all of it is written in a declarative style.
That doesn't help most users who aren't going to understand OCaml code. I'd like to do two things.
1. make the existing reference manual more precise
2. write a formal spec
My expected timeline is as follows:
• this week: get the error messages to the point that they are at least as good as those in the existing compiler
• two weeks following that: get the code generation done
• add to that another week to be conservative?
That would get us to the point of a complete beta version of the compiler.
Then, we'd need time to integrate it with CmdStan, RStan and PyStan. I have never worked on that code so don't know how much work it would be. Perhaps @seantalts could give an estimate?
There's no integration required---stanc is a standalone program that translates a Stan program (with includes) to a .hpp class definition.
|
Hi, |
This is still broken on develop so it'll still be broken in the pending 2.19 release.
We should fix it for 2.20 even if the OCaml parser isn't out. We'd decided not to fix any more bugs in the existing C++ parser pending the new one coming out. The problem is that it's taking way longer than anticipated to get the OCaml going and there's no end in sight yet.
|
I think we have another month and a half left until we're over the original 6 month budget no? Something like that. |
Thanks for your response. However, I receive the error "variable real does not exist." If I don't use the brackets above, I receive the error "variable else does not exist." Thanks |
Can you paste an entire (ideally minimal failing example) model somewhere?
I'm confused about what you mean by "function block inside the model block"
as that shouldn't work. Functions need to be defined in a separate block
outside of the model block. The temporary fix should just be to use the
braces on the else clause.
On Wed, Mar 20, 2019 at 03:00 msadeghpour ***@***.***> wrote:
Thanks for your response.
In my model block, inside the function block, I have this:
real r1;
real r2;
if (x_i==1){
r1 = 0.2;
r2 = 0.2;
}
else if (x_i==2){
r1 = 0.2;
r2 = 0.5;
}
However, I receive the error "variable real does not exist." If I don't
use the brackets above, I receive the error "variable else does not exist."
I was wondering if currently there is a fix for this? In general, can I
use if-else statements in the function block that is inside the model block?
Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2697 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAxJ7G82kUhp19J5yJxw2MGMgmeywaOEks5vYaRUgaJpZM4Yn9TS>
.
--
📲
|
The failing example is in the original issue:
It works if you put braces around the bodies, but it should work this way, too. |
Oh, I thought the person had a new failure. Never mind.
…On Wed, Mar 20, 2019 at 8:02 PM Bob Carpenter ***@***.***> wrote:
The failing example is in the original issue:
model {
if (1)
print(5);
else
print(4);
}
It works if you put braces around the bodies, but it should work this way,
too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2697 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAxJ7Nbk42Ut_ywC1gEmvATrQ77evtSjks5vYpPYgaJpZM4Yn9TS>
.
|
Fixed in stanc3. |
Summary:
Conditional control flow constructs have strange parsing behaviour with block structure.
Description:
For an if-then-else statement, it seems that we are required to specify a block statement for the then-clause. Arbitrary statements seem disallowed.
Reproducible Steps:
Try to compile
Current Output:
SYNTAX ERROR, MESSAGE(S) FROM PARSER:
Variable "else" does not exist.
error in 'stan/src/test/test-models/good/if-else-blockless.stan' at line 4, column 9
Expected Output:
I would expect this to parse just fine.
Current Version:
v2.18.0
The text was updated successfully, but these errors were encountered: