== EXAMPLES & UNIT TESTS ==

* Review all examples to choose what is the best alignment for each
  one (i.e., are they using dictionary only because at the time it was
  the only option?)

* MediaWiki

** annotated regexps

** safe bijections

* Choose a way to organize unit tests (and do it)

* Tests with weight and predicates for each kind of alignment

* Add text with all alignments nested one within the other and
  make some easy tests (just to check that the alignments are
  interacting well)

* Test alignments when the string does not have any chunk (in
  both sides and only in one side at a time). like put "" into ""

* unit tests for weight (with flag force = false and true)

== SYSTEM ==

* the implementation of the function cast rule is sound, but actually
  checks too much.  we should implement the function check rule that
  has been proven sound. (Mike)

* being able to match a list "[a;b;c]" in a match branch 
  instead of match l with
     | List.Cons (a, (List.Cons (b, (List.Cons (c, List.Nil)))))

* name resolution in a submodule (see BUGS)

* -check-only flag: don't compile and run, just check that base sorts
  line up.

* better error messages on bad overloading resolution (usually caused by a type issue elsewhere)

* optimization and speedups (profiling indicates lots of GC activity)

* warning if something is being redefined (and a command line argument to activate this)

* Extend Boomerang grammar to accept pairs like ocaml: "let f (x,y:int*int)"

== TOP LEVEL SYSTEM ==

* toplevel

** functions to process command-line arguments from boomerang (set
   solutions mode for coqsplit): done, coqsplit to do

* Configuration management

** Boomerang only

** Whole document with Unison

*** Bsync

*** unison interface

== DOCUMENTATION ==

* Polish intro of manual.

* When starting to talk about regexp, point to a reference and say
  that the syntax in Boomerang is different, but the idea is the same.

* QuickStart:

** Add examples using q-lenses to QuickStart.

* Regexp: if someone does not know what is a regular expression?
  Indicate a reference in regular expressions somewhere.

* Documentation for XML library?

* Prefs module missing documentation

* Polish exception.boom and write a documentation

* Fiat description is not very clear (need a simple example; why is it useful?)

* Write some techniques to write lenses:

** Warn the user to use regexp as long as possible and only write lenses
   when he can not continue using regexp.  Example:
   (del R)*  and  del (R*)   where R:regexp

* Review core.boom, prelude.boom, etc to check if the documentation is
  matching with the functions. Also, write some more examples.

* Explain let types/contracts
   - let f (x:t1) (y:t2) =
   - let f (x:t1) (y:t2) : t3 =
   - let f (x:t1) : (t2 -> t3) =
   - let f (x:t1 where cond1) (y:t2 where cond2) : (z:t3 where cond3)
   - etc.


== PRINTING ==

* Lens printing is currently deficient

** re-do lens printing entirely

** using clobber as our implementation primitive means that we can't
   print useful lens representations for const, ins, etc.

** we _have_ enough information to print canonizer_of_lens well, but
   the two types are currently defined separately in different modules...

* Printing for lists (instead of printing the structure)

== UNIT TESTING ==

* unit testing

** programmatic blame

*** more specific "this code raises blame" tests

** desugar test syntax into DLet, eliminate DTest

== CODE ==

* core.boom vs. prelude.boom

* Split some .ml files (balign.ml for example)

* Use heap in greedy alignment

* Fix names "Permutations" in blenses (permutations writen by users
  in boomerang) and "Permutation" in balign

* Bstring.toplevel (or the caller) should check that for each tag at
  the toplevel, there is no apparence of location for this tag outside
  the toplevel.  This would be a mistake.  Or do we this in the in the
  type checking.

* Fix the way strings are printed in unit tests.  They are not
  escaped.  Eventually try to print them in boomerang format if the
  need escaping.  For example:
  "foo" -> "foo"
  "blah\nfoo\"blah\"" ->
  <<
    blah
    foo"blah"
  >>

== OTHER ==

* Done: "dynamic tags (this is necessary, e.g., for pdict)", but what is pdict?

* coqsplit (was in the summer agenda of the trunk's todo)

== BUILD ==

* add target for bytecode compilation (Nate)

== LIBRARIES ==

* Investigate other options for the contract on sorting.

* Work out standardized WS/WSP/NL* regexps

* Fix contract on q-lenses using crel/arel/cnrel.

* Various ISO formats, e.g. ISO8601 dates 
** http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874

* Encodings and numbes: Base64, hex, scientific notation
** can we write a lens in hex <-> decimal?  which primitives must we add, if any?

== EXTENSIONS ==

* cross-reference in the documentation ("it would be even better if
  the identifiers are hyper-linked to the chapter/section describing
  it's aim and use, in order to improve the manual browsing")

* find a solution to read from stdin (for the main function) ;
  [read '-'] fails now ; give a readLine/readChar?

* add ambiguous concat on left and right:
  a* -. a* with "aa" gives ["aa", ""]
  a* .- a* with "aa" gives ["", "aa"]

* coercion from aregexp to lens

* asymmetric lens

* unicode

* nested words and recursion

** string <-> tree

