Contributions

How

Assumptions: you have knowledge of how git and github works, as well as basic usage of the library.

The first step would of course be to familiarise yourself with the code. If your interest lies in writing concept instances for some additional or new type, then the natural thing to look at would of course be the existing instances of said type class. These are generally found in a header with the name of the data type. E.g., all concept instances for std::list are found in the ftl/list.h header.

If there is some functor, monad, or other concept operation you miss, the place to look is naturally at the existing function objects fmap, mbind, fold etc and do something similar. These are generally found in the header corresponding to the concept in question, such as ftl/concepts/applicative.h.

In general, always try to follow/mimic the existing style, level of documentation, and naming scheme. Further, make note of how most of the "functions" provided by the library are actually empty structs with an operator(), inheriting from make_curried_n. This is to make sure as much as possible of FTL itself plays nice with curried calling conventions (and is therefore cleanly usable in applicative style), while ideally not incurring any run-time overhead—at least not with optimisations turned on.

Once you've created some contribution that you think is a worthy addition, it's almost time to open a pull request. Note, however, that changes that break the unit tests will not be accepted. Preferably, you should make sure of this before opening the pull request by compiling and running them yourself, but they will also be run automatically by travis after the request is opened and you should always check the result there too.

What

Whether it's new features, bug fixes, better test coverage, more examples, or documentation improvements, all contributions are welcomed with open arms. Here follows a short list of items that are presently in demand, sorted roughly in order of effort/knowledge required:

• Additional examples in the in-source documentation. Basically, any function, struct, or other named thing part of the public API that is currently without examples should eventually have one or more.
• Increase test coverage with further unit tests. Any code path not currently covered is fair game.
• Further material in the style of the parser combinator examples.
• Experiment freely with implementing your favourite Haskell type class or data type and evaluate its usefulness in the context of FTL—if it seems to work well, propose its addition to the library
• Add tests to make sure the static guarantees the library claims to make actually hold. For example: write a minimal program that should fail to compile because it uses non-exhaustive pattern-matching, then add its build to the test script and make sure it fails.
• Rewrite the test system to something a bit more elegant; possibly through some existing test framework
• A separate library or application (even if it's just a mockup) that actually uses FTL, followed by a report on things that seem to be missing, object/method usage patterns that aren't covered, things that were useful, things that were not, bugs found, and so on.

Some of these are likely to be more or less permanent points, while others will be checked off as they're deemed fulfilled. New items may of course also be added from time to time.