Monads and do-syntax for Elixir
Latest commit 9f3f2bf May 18, 2016 @rmies Merge pull request #11 from he9lin/feature/reader-pipeline
Add pipeline for reader monads
Failed to load latest commit information.
lib Add reader pipeline test May 18, 2016
test Add longer chain May 18, 2016
.gitignore Update to Elixir v.0.12.2 Jan 21, 2014
.travis.yml Update elixir version for travis Dec 11, 2014
LICENSE Update license file Aug 11, 2014 add Hex badges Aug 16, 2014
mix.exs Version bump 1.0.5 Oct 22, 2015
mix.lock Update "ex_doc" version Dec 12, 2014
package.exs Version bump 1.0.5 Oct 22, 2015


Build Status version downloads

This library provides do-syntax and monads for Elixir. It is heavily inspired by Haskell.

Contributing Guidelines

To contribute:

  1. Fork the monad repository on GitHub.

  2. Clone your fork or add the remote if you already have a clone of the repository.

     git clone
     # or
     git remote add mine
  3. Create a feature branch for your change.

     git checkout -b feature/name-of-your-branch
  4. Make your change and commit. Use a clear and descriptive commit message, see this note.

  5. Push to your fork of the repository and then send a pull-request through GitHub.

     git push mine feature/name-of-your-branch
  6. We will review your patch and merge it into the main repository or send you feedback.

Coding Style

  • Golden rule: just follow the style of the rest of the code.
  • Avoid unneccesary whitespace in expressions with braces and brackets (tuples / lists). Don't write { :ok, a }, write {:ok, a}. Whitespace is allowed in nested expressions if it significantly improves readability, but if things get that complicated prefer to rewrite the expression to be simpler (one spot where that's not always possible is pattern matching).
  • Add documentation to all modules (@moduledoc) and public functions/macro's (@doc). Exception: implementations of callbacks don't need (but may have) documentation, if you leave off the documentation a default will be provided by the documentation generator.
  • In documentation use the first line as a short summary, this will show up in the function/module/whatever overview in the documentation.
  • Line length: limit the numbers of characters per line to 80.
  • Avoid trailing whitespace.

Branching Model

Use Vincent Driessen's branching model (as supported by git-flow, of course you're free to do it by hand).