<commit_before>Hamster
-------

  - [![Version](https://badge.fury.io/rb/hamster.png)](https://rubygems.org/gems/hamster)
  - [![Climate](https://codeclimate.com/github/hamstergem/hamster.png)](https://codeclimate.com/github/hamstergem/hamster)
  - [![Build](http://img.shields.io/travis-ci/hamstergem/hamster.png)](https://travis-ci.org/hamstergem/hamster)
  - [![Dependencies](https://gemnasium.com/hamstergem/hamster.png)](https://gemnasium.com/hamstergem/hamster)
  - [![License](http://img.shields.io/license/MIT.png?color=green)](http://opensource.org/licenses/MIT)

Efficient, immutable, and thread-safe collection classes for Ruby.

Hamster started out as an implementation of [Hash Array Mapped Tries][HAMT] for
Ruby. It has since expanded to implementations of other [Persistent Data
Structures][PDS] like `Set`, `List`, `Stack`, `Queue`, and `Vector`.

Hamster collections are **immutable**. Whenever you modify a Hamster
collection, the original is preserved and a modified copy is returned. This
makes them inherently thread-safe and sharable. For an interesting
perspective on why immutability itself is inherently a good thing, you might
like to take a look at <NAME>'s [Function Objects presentation][FO].

Hamster collection classes remain space efficient by making use of some very
well understood and very simple techniques that enable sharing between copies.

Hamster collections are almost always closed under a given operation. That is,
whereas Ruby's collection methods always return arrays, Hamster collections
will return an instance of the same class wherever possible.

And lastly, Hamster lists are lazy -- where Ruby's language constructs permit
-- making it possible to, among other things, process "infinitely large" lists.
(Note: Ruby 1.9 supports a form of laziness using `Enumerator`. However, they're
implemented using Fibers which unfortunately can't be shared across threads.)

Hamster started out as a spike to prove a point and has since
morphed into something I actually use. My primary concern has
been to round out the functionality with good test coverage
and clean, readable code.

Documentation is sparse but I've tried as best I can to write
specs that read as documentation. I've also tried to alias
methods as their `Enumerable` equivalents where
possible to ease code migration.

[HAMT]: http://lampwww.epfl.ch/papers/idealhashtrees.pdf
[PDS]: http://en.wikipedia.org/wiki/Persistent_data_structure
[FO]: http://www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf


Contact<commit_msg>Fixed typo in README<commit_after>Hamster
-------

  - [![Version](https://badge.fury.io/rb/hamster.png)](https://rubygems.org/gems/hamster)
  - [![Climate](https://codeclimate.com/github/hamstergem/hamster.png)](https://codeclimate.com/github/hamstergem/hamster)
  - [![Build](http://img.shields.io/travis-ci/hamstergem/hamster.png)](https://travis-ci.org/hamstergem/hamster)
  - [![Dependencies](https://gemnasium.com/hamstergem/hamster.png)](https://gemnasium.com/hamstergem/hamster)
  - [![License](http://img.shields.io/license/MIT.png?color=green)](http://opensource.org/licenses/MIT)

Efficient, immutable, and thread-safe collection classes for Ruby.

Hamster started out as an implementation of [Hash Array Mapped Tries][HAMT] for
Ruby. It has since expanded to implementations of other [Persistent Data
Structures][PDS] like `Set`, `List`, `Stack`, `Queue`, and `Vector`.

Hamster collections are **immutable**. Whenever you modify a Hamster
collection, the original is preserved and a modified copy is returned. This
makes them inherently thread-safe and shareable. For an interesting
perspective on why immutability itself is inherently a good thing, you might
like to take a look at <NAME>'s [Function Objects presentation][FO].

Hamster collection classes remain space efficient by making use of some very
well understood and very simple techniques that enable sharing between copies.

Hamster collections are almost always closed under a given operation. That is,
whereas Ruby's collection methods always return arrays, Hamster collections
will return an instance of the same class wherever possible.

And lastly, Hamster lists are lazy -- where Ruby's language constructs permit
-- making it possible to, among other things, process "infinitely large" lists.
(Note: Ruby 1.9 supports a form of laziness using `Enumerator`. However, they're
implemented using Fibers which unfortunately can't be shared across threads.)

Hamster started out as a spike to prove a point and has since
morphed into something I actually use. My primary concern has
been to round out the functionality with good test coverage
and clean, readable code.

Documentation is sparse but I've tried as best I can to write
specs that read as documentation. I've also tried to alias
methods as their `Enumerable` equivalents where
possible to ease code migration.

[HAMT]: http://lampwww.epfl.ch/papers/idealhashtrees.pdf
[PDS]: http://en.wikipedia.org/wiki/Persistent_data_structure
[FO]: http://www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf


Contact
{'fraction_non_alphanumeric': 0.0994496855345912, 'fraction_numerical': 0.0023584905660377358, 'mean_word_length': 4.987058823529412, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 14, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2511077', 'n_tokens_mistral': 1484, 'n_tokens_neox': 1419, 'n_words': 546}