Includes

bugs

#1

How are the interfaces supposed to use includes in 2.16?

I have bar.stan

parameters {
  #include baz.stan
}
model {
  target += normal_lpdf(theta | 0, 1);
}

and baz.stan

real theta;

And I pass the path of baz.stan to compile and get

paths[0] =
/tmp/SU/
SYNTAX ERROR, MESSAGE(S) FROM PARSER:

Warning (non-fatal): Comments beginning with # are deprecated.  Please use // in place of # for line comments.
variable "theta" does not exist.
  error in 'model421549a41e60_bar' at line 5, column 30
  -------------------------------------------------
     3: }
     4: model {
     5:   target += normal_lpdf(theta | 0, 1);
                                     ^
  -------------------------------------------------

It looks as if it is treating #include baz.stan as a comment?!?


#2

Upon further review, it works if the #include statement is flush left. Is that an intended restriction? If so, WTF and it seems to be inconsistent with the manual which says “There are no restrictions on where include statements may be placed within a file …”


#3

Yes, WTF.

I meant to implement it flush left, then I thought you wanted it not flush left, then I think I did implement it flush left, but I documented as general.

How should we fix this? I’d rather leave it all flush left, but could be convinced to generalize. It needs an issue to change the behavior (not hard) or a comment in the next manual issue to change the doc.

This really shouldn’t have even been in the manual until people could use it.


#4

I vote arbitrary whitespace before the include given that one might want to include into an existing block, typically the functions block, and maintain the expected whitespace.


#5

I think that’s what everyone wants. So I added an issue:

https://github.com/stan-dev/stan/issues/2358

Only question is whether we include the space up to the # on the line?


#6

Cool. I think it would be preferable not to include the space up to the #, but I don’t feel strongly about it.