From d2ab44d26101887316d7537c37eb27533985184f Mon Sep 17 00:00:00 2001 From: Siraaj Khandkar Date: Mon, 5 Jan 2015 17:31:13 -0500 Subject: [PATCH] Describe what is currently implemented. --- README.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/README.md b/README.md index f329853..e5578b4 100644 --- a/README.md +++ b/README.md @@ -4,3 +4,33 @@ Higher Order Programming in Erlang ================================== A quest for a "standard" library with uniform, composable abstractions. + + +Monads +------ + +Defined in `hope_gen_monad`, implemented as: + +- `hope_result`: for composition of common functions returning + `{ok, Val} | {error, Reason}`. An alternative to exceptions, which makes the + error conditions apparent in the spec/signature. Analogous to Haskell's + `Data.Either a b`, Jane Street Core's (OCaml) `('a, 'b) Result.t`, Rust's + `Result` +- `hope_option`: for expressing and composing the intention that the value may + or may not be available. An alternative to the common `undefined` (which is + equivalent to the dreaded `null`). Analogous to ML's (SML, OCaml, etc) + `'a Option.t`, Rust's `Option` and Haskell's `Data.Maybe a` [1]. + + +Containers +---------- + +### Dictionary + +Defined in `hope_gen_dictionary`, implemented as: + +- `hope_kv_list`. Equivalent to orddict/proplist. Operations implemented with + BIFs from `lists` module, where possible + + +[1]: http://en.wikipedia.org/wiki/Option_type -- 2.20.1