Milestones

Summer school

Definitely

Documentation for:
- ERP
- Header functions (the important ones at least; clean-up header first)
- I/O + common data munging techniques (e.g. an elaborated version of this) this
- query.table and globalStore (and recommendations for I/O)
- Inference docs (basic docs for core algorithms are already done)
  - document custom / drift proposers (and make sure they work, eg #231, #308)
- Let's include coarse information about time/space complexity as functions of # variables, trace depth, etc. This will help users select appropriate inference methods. (we should evaluate if these coarse metrics are actually useful.)
- Installation/basic usage docs (review that they are clear)
Provide a solution for larger datasets
- This probably means: implement variational inference, test on some examples (e.g. LDA with realistic sets of documents; census data). Need to evaluate scaling of other algorithms (eg HMC) wrt number of variables and size of data.
Better error messages I
- Hook syntax errors up to the editor.
- Run-time errors. Show the webppl code which caused the error. (#22) 'Full' stack trace, at least in debug mode.
Simple IO (subset of #146?) for student projects:
- Read/write text and csv files
- Save samples and ERPs to disk
  - How? By making '--require fs' work (#278), via a package, or helpers in core?
- I don't think it's necessary to provide any of this in the browser
Update the browser editor (Long)
More auto-visualizations (Long)

Maybe

Writing helper functions for testing convergence (e.g., autocorrelation function, Geweke testing). (#46)
Generate visualizations from node (e.g. by controlling browser window) (#130) (enough to make svg/pdf file that can be viewed in browser?)
Linked lists instead of arrays? (My thinking here is that I've seen this cause out of memory problems a few times and it might not be fun if we run into this at the summer school. However, you can often get around the problem by moving the work from webppl to js, and if we get really stuck we can try my linked list package. The fact that this doesn't seem to come up very often perhaps suggests we can manage without it, providing nobody brings too much data?)
Better error messages II
- Run-time argument checking with nice errors for ERP and inference args? (Similar to what we have for probmods.)
- Generate readable errors on invalid webppl code that is valid js code.
Make it easier to require js code without packages (#211)
We should decide what, if any, environments we want to support:
- IPython / Jupyter Kernel -- Notebooks reduce the friction of model exploration (also, we can shift the visualization burden to R/python)
- Perhaps an R package bridge between R and WebPPL a la RStan (MH)

Definitely

Stable inference interface (#86))
Stable ERP interface (#268)
Reconsider what subset of Javascript we want to support
- Because it's so simple, support FunctionDeclaration (#2)
- Is there some explicit principle we're following?
- Consider (parts of) ES6 for webppl programs
- After V1, the language we support should remain unchanged for a while
Fix ERP bugs (do we have a list?)
- Make binomial approximation consistent and explicit (#219)
- Beta shouldn't return NaN (#269)

Maybe