Skip to content
Long Ouyang edited this page Dec 4, 2013 · 1 revision

participants

  • noah
  • erin
  • julius
  • long

scheme syntax

we might want to change the scheme syntax because students think parentheses can be used for grouping. noah says there is a spec for a prettier scheme, with significant whitespace and function names in front of parentheses. supposedly there is a srfi for this.

noah understands the syntax worry, but also worries about moving off of the whole mass of scheme infrastructure we've developed. but he can be convinced by data we've collected (e.g., if there are just way too many parens errors).

TODO: analyze the data that we've collected.

code saving

idea: switch to: couchdb serverside, backbone+pouchdb clientside

book content

noah still needs to go through last chapters and revise them.

q: how close are we to getting the hard-to-initialize examples to work?

a: somewhat close, but also fairly far (some complicated work remains; webchurch-opt currently handles many cases but sometimes runs forever). this is a low-priority todo, since we can often restructure code to make conditions simpler.

webchurch

  • revising visualizations
  • liveupdating plots? (not high priority) may interact with new thunk semantics and webworkers
  • new thunk semantics for query: query functions return a thunk that gives you a sample?
  • webworkers for longer-running programs, side-effects
  • move graphics into webchurch (half done)
  • error checking
    • julius: would be nice to have a taxonomy of errors (e.g., there is class of errors where a function is being called and something inside that function breaks, but the function gets blamed [e.g., this happens when a function is called inside a case statement])
    • does this work firefox? (may not be solvable)
  • benchmark suite
    • add stats like autocorrelation, runtime, accept-reject ratio

usefulness for science

  • more command-line niceties for webchurch (e.g., system for passing arguments to webchurch code, no documentation on command-line stuff)
  • syntax highlighting for different editors (e.g., vim, emacs)
  • apparently michael henry has had problems with node install on windows?
  • documentation for functions. at least have a differences-between-church-and-scheme quick reference.

editor

  • save to file / load from file (TODO: add this to github issues)
  • add line numbers (make this optional)
  • different highlighting for ERPs (erin has done this, a TODO for her is to push it) and queries

book maker / report maker

  • after Makefile branch of chaptesr gets merged in, let's have people try making a few reports
  • might want to explore a notebook-like interface

probjs

  • stateful erps (also matters for last couple of chapters in books). this is easy to do, noah just needs to do it.

visualizing control flow

utah guys have a working implementation of church control flow analysis. one of the tools will draw the bayes net of a sufficiently simple church program. one of the tools works on all the code in chapter 1.

personnel

julius will actually be staying with us. orren will probably not join us.

going forward

do refactoring first failing any actual programming work, make sure we write down the todos so we have institutional knowledge