Stan the Gathering: Sept 2, 2021, 11 am EST

Meetings
1

Hangouts Link: https://meet.google.com/gzm-wmum-pfm

Instructions: Ask to attend in the hangouts interface and someone should let you in in the first 10 minutes of the meeting. Email mitzi212@gmail.com

Please add your agenda items in replies.

1 Like
2

The hangouts link now has a 1-hour limit, which is not a bad thing.
Last week a few things were brought up but we didnā€™t have time to discuss, these being:

  • making good on our promise to deprecate language features, e.g. assignment via <- .

  • how to help developers find answers to C++ releated questions, especially if theyā€™re interested in contributing to the code Stan libraries? it seems that now thereā€™s both slack and zulip forums, also maybe wiki pages - as always, different folks ask differently - how can we help them?

  • how to insure that the official Stan docs get updated as new features are added to Stan? and how to insure that all additionals to the docs render properly - before a PR gets merged, should reviewer sign off that HTML version of docs rendered on their machine?

if thereā€™s interest, we can discuss them - if not, noted here.

1 Like
3

I am not sure I will be able to make it to the meeting and I dont really know what was discussed in the last meeting. I just want to give my 2 cents, for whatever its worth.

I feel this question is essentially how and when are we going to do the next major release of Stan so I guess we can discuss on when to do that. There is a lot of code that can be removed once we decide on doing that: deprecated language features like # and <-, *_log functions, print cmdstan functionality, stanc3 arguments etcā€¦

4

I think there are two facets of this discussion. One is what would we want to see in a Stan 3.0 that would also feature a lot of deprecation removals, but the other part is what amount of backwards incompatibility are we willing to accept in minor releases, e.g. removing a several-years deprecated feature, or introducing a new reserved word. In particular, if the later requires a major release to justify, features like complex numbers (or really any new type or language feature) are now major-release only, or lead to some pretty serious hacks in the implementation to work around not reserving the keywords required

So anyway, I want to discuss with a broader group what people think are reasonable ways forward there, and then hopefully that can inform the later meeting Bob is organizing about future language work

3 Likes
5

there are lots of people who wonā€™t be at the meeting and therefore probably arenā€™t even reading this thread. in order to get more input, I suggest making a new post.

6

My plan was to get some initial thoughts and opinions in the meeting and then create a post. Iā€™m sure there are options that havenā€™t even occurred to me, and I want to hear some before writing down a proposal or suggestion. A post will follow for sure!

2 Likes
7

Aki wants to discuss issues with posterior package and ESS-tail

8

Ben Goodrich is discussing his design doc for quantile functions: Designs/0028_quantile_functions by bgoodri Ā· Pull Request #42 Ā· stan-dev/design-docs Ā· GitHub

1 Like
9

We have introduced a ton of new functions over the years and have never considered to do a major release. Thatā€™s a bit different as it can be resolved by context, but at one point we even had all of a sudden ā€œoffsetā€ being a not permissible name for variablesā€¦ which we took back as it conflicted with many written programs. In short, adding things is usually fine, taking things away is not. Kind of that is what has been followed. Or would existing (and regular) programs break by the change you introduce?

10

I think introducing new keywords is important for growing the language. What we have done with offset (and the new array syntax) to avoid adding them as keywords is going to build up technical debt in the long term[1], so I think itā€™s important to have some process by which minor[2] backwards-incompatible changes can be introduced with a deprecation period (we would emit warnings saying something like ā€˜hey, rename this variable before x version!ā€™).

Iā€™m going to make a full post to discuss this idea in more detail soon, but that is the gist.

Edit: full post here

[1] Really more like the short term, there are already programs which emit the wrong parser error as a result of the array syntax and as far as I can tell they cannot be fixed unless/until array is a reserved word
[2] By minor I mean ā€˜can be fixed with find and replaceā€™ or, even better, 'can be fixed by using stanc3 --print-canonical'. This means reserved words or one-to-one syntax changes like removing <- in favor of =, but not necessarily things like the new ODE solvers

2 Likes