Space before # in includes

Developers
1

Currently, the line-based # includes that are not line initial are not portable across RStan, PyStan, and CmdStan (which means it only works in RStan and PyStan).

Allowing initial space before # comments would be a trivial grammar fix (plus some testing).

I strongly prefer the # to be initial so that it is easy to scan a file for includes. The main purpose of syntactic conventions, in my opinion, is to make files easy to scan, not to make them look pretty.

Until the # comments get deprecated, the current indented syntax is especially easy to confuse with comments; this will improve with Stan 3 when the # comments will be disallowed (they’re already deprecated, so I’m wondering if the interfaces are getting deprecation warnings with their includes).

But I prefer consistency and if this is something that the interface devs feel they need to hack around to create a non-standard language, I guess I don’t feel that strongly about it.

Other opinions here? We may have even decided something about this at some point, but we don’t have any running record of decisions anywhere.

2

This is particularly relevant for @bgoodri and @ariddell and @ahartikainen and @jonah, and in terms of Stan 3 language design, @Matthijs and @seantalts, as this will affect backward compatibility.

3

I created a helper function for #include (under pystan.experimental). It just removes the whitespace.

4

I should’ve put in the reference to your issue, as that’s what caused this post. RStan’s doing the same thing in modifying the language so it doesn’t match CmdStan.

As much as I’d like the interfaces to fix on the CmdStan convention, I may even have already agreed to fix CmdStan to match in the past.

5

I always thought that #include ... should behave like it does in C++, where you can have whitespace before the # and comments afterward.

6

Thanks much for the clarification.

One of my main motivations was to stick to standard conventions. I was absolutely convinced that this wasn’t legal in C++, but it works in clang!

I can submit a patch ASAP.