+
+Conventions
+-----------
+
+I entertain any forward-thinking library design ideas, but more than anything
+else, these are influenced by Jane Street's Core of the OCaml world.
+
+- A module per data type implementation
+- Name of the module is the name of the type
+- Inside the module, the type it implements is always named t(..), such as:
+ `hope_foo:t()`, _not_ `hope_foo:foo()`
+- t(..) is always the first argument
+- Names of private records _may_ be short, such as: `#foo{}` or `#t{}` (Though
+ I'm second-guessing this idea, since seeing `{t, ..}` in stack traces is less
+ than helpful. I'm considering requiring fully-qualified names for all record
+ definitions and maybe short-handing what would've been `#t{..}` as
+ `-define(T, ?MODULE). -record(?T, {..}).`, which may be a bit ugly. Still
+ thinking...)
+- Names of public records _must_ be fully qualified, such as: `#hope_module_record{}`
+- Names of all modules _must_ be fully qualified, such as: `hope_module` (this
+ should go without saying, but just to be sure...)
+- Keep the number of (anonymous) arguments "reasonably" low:
+ + up to 3 is normal
+ + 4 is suspicious but may be reasonable
+ + 5 is _very_ suspicious and probably unnecessary
+ + more than 5 is unacceptable, so consider reducing by:
+ 1. revising abstractions, or, if not practical
+ 2. creating a public record specifically for the purpose of passing
+ many arguents, which simulates labeled arguments. For an example see
+ https://github.com/ibnfirnas/oauth1_core where I used that technique
+ extensively (especially in oauth1_server.erl)
+
+
+Abstractions
+------------
+
+### Monads
+
+A class of burritos, used for sequencing operations on a particular data type.