Why does this site exist ?
When starting to learn Haskell, I needed a project to help me focus on the details. I'd already written my first Haskell-program; a small, but useful, program to optimise the packing of files into a backup-medium of limited space; but I needed a more substantial task. I decided to write a Contract Bridge program; the task seemed well contained, & whilst chess-programs were so common you were unlikely to see the same one twice, I couldn't find any open-source bridge-programs. There were a few commercial bridge-programs, but I know from bitter experience of commercial consumer-software that; they'd only run on MS-Windows (though perhaps also on wine); they're unlikely to live-up to the advertised claims; I'll lose the product-key.
Bridge, for the uninitiated, is a card-game based on winning tricks, but unlike Whist, the card-play is preceded by an auction, in which the four players, acting as two opposing partnerships, bid to establish a contract to make a specific number of tricks. Each player bids in turn, but not solely on the basis of the known cards in their hand, but also attempting to account for the unknown ones in their partner's. Thus a bid serves different roles; primarily to establish the winning contract, but also; to supply information about the bidder's hand; to request information regarding their partner's hand, so that the partnership may subsequently estimate that ultimate contractual bid; or just to frustrate your opponents' attempts to achieve the same. Even if a partnership fails to secure the contract, the bids may also contain the clues to the structure & strength of each player's hand, necessary to mount an effective defence.
The bids from which the auction is composed, form a vocabulary in which there are only 38 words. Though this is all that is required to establish any of the 35 possible contracts, it represents a crippling speech-impediment when attempting to describe the vast number of hand-combinations which may have been dealt. To compensate for the discrepancy between this restricted vocabulary & the wide variety of hands, the bidding-sequence is used to impart more information than the isolated bids. Though the auction's final constructive bid still represents the contract which must be achieved, the bidding-sequence leading up to it, may be used to convey or request information about the shape & strength of a hand, unrelated to the literal interpretation of individual bids.
The meaning of various bidding-sequences is conventional, rather than chiselled into stone tablets amongst the rules of the game. Since the game is competitive & players strive to communicate more efficiently, these conventions evolve. I've long observed that whilst one can teach someone the rules of chess in an hour, & they can quickly learn to play an effective game, the conventional bidding-sequences of bridge are comparatively hard to learn, & equally hard to program. The set of commonly used conventions is ill-defined, but large, & each one has competing variants.
Bridge ruins all other card-games. After learning to play it, the justification for the time required to play any other card-game, seems rather thin.
The bridge-program got steadily larger, but little closer to the home-straight, as I realised the magnitude of the task; since in contrast to for example Chess, it's a game of imperfect information. On the way, it spawned a requirement for a regex-engine which could scan sequences of bids, rather than the traditional task of scanning text; so I wrote a polymorphic regex-engine, which could then be specialised to search for conventional bidding-sequences.
The Bottom Line
Whilst this site contains the completed part of this original software-project (available as open-source), my attention began to wander towards other software-projects using Haskell, notably a school-timetable solver & a chess-program; & to projects based on the Raspberry Pi. Navigate via the graffiti above.