Difference between revisions of "How to write a Haskell program"
DonStewart (talk | contribs) (Start on a 'write your haskell project' guide) |
DonStewart (talk | contribs) (notes) |
||
| Line 18: | Line 18: | ||
benefits everyone -- a set of common tools increases productivity, and |
benefits everyone -- a set of common tools increases productivity, and |
||
you're more likely to get patches. |
you're more likely to get patches. |
||
| + | |||
| + | Advice: |
||
| + | * Tag each release |
||
| + | * Make sure you also release tarballs, '''darcs dist''' can do this automatically |
||
== Build system == |
== Build system == |
||
Revision as of 01:56, 25 October 2006
A guide to the best practice for creating a new Haskell project or program.
Licenses
Library code for the base libraries must be BSD licensed. Otherwise, it is your call. Choose a licence (inspired by this). Check licence of things you use, both other Haskell packages and C libraries. Use same as related where possible. Haskell community is split into 2 camps, roughly, those who release everything under BSD, and GPLers. We recommend avoiding LGPL, due to cross module optimisation issues.
Revision control
Use Darcs unless you hve a specific reason not to. Almost all new Haskell projects are released under Darcs, and this benefits everyone -- a set of common tools increases productivity, and you're more likely to get patches.
Advice:
- Tag each release
- Make sure you also release tarballs, darcs dist can do this automatically
Build system
Ues Cabal.
Documentation
Use Haddock.
Testing
Pure code can be tested using QuickCheck. Impure code with HUnit.
Program structure
Monad transformers are very useful for programming in the large, encapsulating state, and controlling side effects.