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 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 or monad operation you miss, the place to look is naturally at the existing function objects fmap, mbind, 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 adding 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 of 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 (i.e. any function, struct, or other named thing currently without examples)
• Increase test coverage
• 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
• 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.