These exercises are based on the class discussion about writing Lisp code for playing Poker. I deliberately use simple lists for representing cards and hands, so that you can practice using Lisp's many list and sequence functions. Do not re-invent the wheel!

Many Lisp programmers would do this with classes in CLOS for cards, hands, decks, and so on, but that's for another day and chapter.

It's easy to find pages describing how Poker is played. I found this site very useful.

A playing card will be represented as a list of two items: the rank and suit. The rank is either a number between 2 and 10, or the symbol J, Q, K or A, for jack, queen, king or ace, respectively. The suit is the symbol C, D, H or S, for club, diamond, heart or spade, respectively.

Note: there is no 1 rank.

A hand is a list of cards. Typically, we'll assume a standard hand of 5 cards, but try to make your code as general as possible, to handle 6 or 7 card hands, if we wanted. An example hand would be ((5 h) (2 c) (a d) (5 c) (q s)).

Exercise name: get-hand-rank

Function name: get-hand-rank

Define (get-hand-rank hand) to return the rank of a Poker hand, as defined at this site. In particular, it should return one of the following symbols for any hand: royal-flush, straight-flush, four-of-a-kind, full-house, flush, straight, three-of-a-kind, two-pair, one-pair, or high-card.

Follow the process we did in class:

• Program test-first, using lisp-unit. Think carefully about good positive and negative test cases. Run those tests before coding a solution. A few test cases developed in class are here.
• Take small bites. Define tests for one category, then make that work, then work on another. Think about which category seems like the simplest one to do first. It may or may not be three-of-a-kind.
• Follow the cardinal rule and define subfunctions for each algorithmic subtask. The goal is clear, simple, readable code.
• If the subfunction you define is non-trivial, stop and define a separate set of test cases for it first. Make sure the subfunction passes its test cases before continuing work on the main function. A subfunction is non-trivial if it's at all likely you could get it wrong.
• Don't let functions get long. When you're about to add code to a function and it looks like it will become too long, refactor! When you refactor existing code, you don't need to write more tests, but you should re-run the tests you have to make sure you didn't break anything.

poker.lisp defines the tests and code in a package called :poker. The simplest way to develop your tests and code will be to

1. load poker.lisp
2. switch to the :poker package by typing (in-package :poker)
3. run all the tests in the package by typing (run-tests)
4. use your file editor to add tests or code
5. reload
6. repeat steps 3 through 5 till done

The usual rules for submitting code apply, i.e., one exercise to an email, and all code must work and pass the Lisp Critic.

Include both your tests and your code for each predicate you submit. The Subject line of the email should be get-hand-rank.

All your tests should be at the beginning of the file.

Exercise name: better-hand-p

Function name: better-hand-p

Define a predicate (better-hand-p hand1 hand2) that returns true if hand1 is better than hand2 in Poker. Use the rules given at this site.

As always, define and run your tests before coding a solution. Do the same for any non-trivial subfunctions you decide you need.

Send all your tests and code for this predicate. Use the Subject line better-hand-p.

Comments? Send mail to Chris Riesbeck.