{"id":17483518,"url":"https://github.com/xandkar/hope","last_synced_at":"2025-04-22T14:46:14.812Z","repository":{"id":18330553,"uuid":"21509737","full_name":"xandkar/hope","owner":"xandkar","description":"A quest for a \"standard\" Erlang library with uniform, composable abstractions.","archived":false,"fork":false,"pushed_at":"2019-12-10T18:59:40.000Z","size":70,"stargazers_count":18,"open_issues_count":10,"forks_count":5,"subscribers_count":7,"default_branch":"master","last_synced_at":"2024-10-19T03:06:32.830Z","etag":null,"topics":["erlang","standard-library"],"latest_commit_sha":null,"homepage":"","language":"Erlang","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/xandkar.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-07-04T23:29:38.000Z","updated_at":"2022-10-23T14:24:30.000Z","dependencies_parsed_at":"2022-09-02T18:01:20.139Z","dependency_job_id":null,"html_url":"https://github.com/xandkar/hope","commit_stats":null,"previous_names":[],"tags_count":32,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xandkar%2Fhope","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xandkar%2Fhope/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xandkar%2Fhope/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xandkar%2Fhope/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/xandkar","download_url":"https://codeload.github.com/xandkar/hope/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250262452,"owners_count":21401682,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["erlang","standard-library"],"created_at":"2024-10-19T00:05:46.435Z","updated_at":"2025-04-22T14:46:14.791Z","avatar_url":"https://github.com/xandkar.png","language":"Erlang","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![Build Status](https://travis-ci.org/xandkar/hope.svg?branch=master)](https://travis-ci.org/xandkar/hope)\n\nHope\n====\n\nA quest for a \"standard\" library with uniform, composable abstractions.\n\nOriginally motivated by a desire for an error monad and generic option type\noperations, and stood for _Higher Order Programming in Erlang_. Soon after, I\nwished all standard containers used consistent conventions and protocols (such\nas consistent accessor names, argument positioning rules and expression of\nsemantics with option and result types).\n\nHere lies an experiment to see what something like that could look like. As all\nproper experiments should, this one is used daily in production projects (hence\nthe high-ish version number, 'cause semver).\n\n\nConventions\n-----------\n\nI entertain any forward-thinking library design ideas, but more than anything\nelse, these are influenced by Jane Street's Core of the OCaml world.\n\n- A module per data type implementation\n- Name of the module is the name of the type\n- Inside the module, the type it implements is always named t(..), such as:\n  `hope_foo:t()`, _not_ `hope_foo:foo()`\n- t(..) is always the first argument\n- Names of private records _may_ be short, such as: `#foo{}` or `#t{}` (Though\n  I'm second-guessing this idea, since seeing `{t, ..}` in stack traces is less\n  than helpful. I'm considering requiring fully-qualified names for all record\n  definitions and maybe short-handing what would've been `#t{..}` as\n  `-define(T, ?MODULE). -record(?T, {..}).`, which may be a bit ugly. Still\n  thinking...)\n- Names of public records _must_ be fully qualified, such as: `#hope_module_record{}`\n- Names of all modules _must_ be fully qualified, such as: `hope_module` (this\n  should go without saying, but just to be sure...)\n- Keep the number of (anonymous) arguments \"reasonably\" low:\n    + up to 3 is normal\n    + 4 is suspicious but may be reasonable\n    + 5 is _very_ suspicious and probably unnecessary\n    + more than 5 is unacceptable, so consider reducing by:\n        1. revising abstractions, or, if not practical\n        2. creating a public record specifically for the purpose of passing\n           many arguents, which simulates labeled arguments. For an example see\n           https://github.com/xandkar/oauth1_core where I used that technique\n           extensively (especially in oauth1_server.erl)\n\n\nAbstractions\n------------\n\n### Monads\n\nA class of burritos, used for expressing sequences of operations on some data\ntype.  Defined in `hope_gen_monad`, implemented as:\n\n- `hope_result`: for composition of common functions returning\n  `{ok, Val} | {error, Reason}`. An alternative to exceptions, which makes the\n  error conditions apparent in the spec/signature. Analogous to Haskell's\n  `Data.Either a b`, Jane Street Core's (OCaml) `('a, 'b) Result.t`, Rust's\n  `Result\u003cT, E\u003e`\n- `hope_option`: for expressing and composing the intention that the value may\n  or may not be available. An alternative to the common `undefined` (which is\n  equivalent to the dreaded `null`). Analogous to ML's (SML, OCaml, etc)\n  `'a Option.t`, Rust's `Option\u003cT\u003e` and Haskell's `Data.Maybe a` [1].\n\n\n### Containers\n\nA class of abstract data types to which we have exclusive access and can put\nthings in and take them out. See issue #9\n\n- Operations on all abstract types of containers _should_ share a common lexicon\n- Concrete implementations of an abstract data type _must_ be swapable\n\n#### Dictionary\n\nDefined in `hope_gen_dictionary`, implemented as:\n\n- `hope_kv_list`. Equivalent to orddict/proplist. Operations implemented with\n  BIFs from `lists` module, where possible\n\nTBD:\n- `hope_hash_tbl`. API around stdlib's `dict`\n- `hope_gb_dict`. API around stdlib's `gb_trees`\n\n#### Set\n\nTBD:\n- `hope_hash_set`. API around stdlib's `sets`\n- `hope_gb_set`. API around stdlib's `gb_sets`\n\n#### Queue\n\nTBD\n\nShould include both FIFO (queue) and LIFO (stack), so that user can swap if a\ndifferent order is desired.\n\nShould we attempt to include priority queues or make them a separate abstract\ntype?\n\n#### Sequence\n\nTBD\n\nNot yet defined and only partially implemented as:\n\n- `hope_list`\n\n\n### Resources\n\nA class of abstract systems to which we share access with an unknown number of\nusers and can make requests to perform operations which may not get done for\nany number of reasons.\n\n#### Storage\n\nTBD\n\nSee issue #11\n\n\n[1]: http://en.wikipedia.org/wiki/Option_type\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxandkar%2Fhope","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fxandkar%2Fhope","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxandkar%2Fhope/lists"}