30.1 Write a program to help process the election totals.(3 steps)

30.1.1 (Display page) Here are the project details.
Miniproject 3

Background
Presidential elections in the United States happen every four years. On November 2 of 2004, for instance, we chose between George Bush and John Kerry for president. The procedure for determining the winner of the election is somewhat complicated, and is described here; in short, the candidate who gets the most popular votes in a particular state earns that state's electoral votes, and whoever gets more than half of all the electoral votes wins the election.
Assignment
Write and test a program to process U.S. presidential election results. The program will include a procedure named winner, whose first argument is a sentence giving the number of electoral votes for each state and whose second is a sentence giving the percentage of popular votes for the Republican and Democratic candidates. (For this assignment, we ignore third-party candidates.) Winner returns either republican, democrat, or #f, depending on who wins the election. Each word in the electoral vote sentence has four characters. The first two are the state abbreviation; the last two are digits that together specify the number of electoral votes for the state. An example is ca55, which says that California has 55 electoral votes. Each word in the vote results sentence has six characters. The first two are the state abbreviation, as with the electoral votes sentence. The next two are the (rounded) percentage of popular votes earned by the Republican candidate; the last two are the percentage of popular votes earned by the Democrat candidate. Some examples from the 2000 election are

ca4254 George Bush earned 42% and Albert Gore earned 54% of the California votes.

dc0986 Bush earned 9% and Gore earned 86% of the District of Columbia votes.

id6928 Bush earned 69% and Gore earned 28% of the Idaho votes.

fl4949 Bush and Gore both earned 49% of the Florida votes.

A framework file that provides the electoral votes for each state and the 2000 election returns is available here. You should use smaller test arguments. You should not make any assumptions about the order of words in the argument sentences, nor make assumptions about what the states are or how many of them are in the argument sentences. If both candidates get an equal percentage of votes in a state, neither candidate should get that state's electoral votes. Otherwise, every state is winner-take-all. That means there are two ways for winner to return #f. One is the situation where each candidate gets exactly half the total electoral votes. The other is where one candidate receives more votes than the other, but because of a tie in one or more states, the candidate with more votes doesn't get more than half the total.
Miscellaneous requirements
Put your solution program into a file named winner.scm in your mp3 directory, and your tests (described below) into a file named winner-tests.scm in the same directory. Submit it as detailed below. None of your code may use recursion. Use the higher-order procedures every, keep, and accumulate instead. In general, restrict your use of Scheme to material covered in Simply Scheme chapters 1-10. Your program should include auxiliary procedures to be called from winner; none of your procedures should be a big mess. You will lose points for unnecessarily duplicated code; define procedures with extra placeholders (possibly procedures) to avoid this duplication. Provide names for your procedures and their parameters that clearly indicate their types and use. Also provide comments with your code. Your grade on this assignment will include evaluation of your comments. Each of your procedures must be accompanied with comments that describe each input—is it a sentence, a word, or a number? what kind?— along with the result returned.
Testing
Include test expressions in a file named winner-tests.scm. Use the testing library discussed in the previous miniproject (a full writeup of its functionality is available here. There is an additional feature described there: in run-test-cases, you can provide an optional argument to run only some of you test cases. Test winner on races where each candidate wins and where neither candidate wins. Include at least one input where two candidates split all the electoral votes evenly, and another where neither candidate earns half the votes. Also test your auxiliary procedures individually, to provide additional evidence that they work correctly. Any procedure that involves a numeric comparison should be tested with values less than, equal to, and greater than the compared value. Any procedure that includes a keep should be tested at least with one input for which all the elements are kept, another for which nothing is kept, and a third for which some but not all of the elements are kept. (Note that these tests are not guaranteed to remove all your bugs.)
30.1.2 (Display page) Your programming style matters!
We will be considering style more strictly than with previous miniprojects, and it will be reflected in your grade.

Keep procedures small. Procedures should tackle small, coherent tasks. They should probably only be a handful of lines of code (not including comments). If you find a procedure doing too many things, think about the subtasks and separate those into sub-procedures. Another benefit of many smaller procedures is that it makes for easy testing.
Choose good names for procedures and parameters. They must be meaningful!
Include adequate comments. In many cases, you need to put meaningful comments both for the procedure as a whole as for parts of the procedure itself.
Avoid nesting conditional statements. In general, nested conditional statements make code harder to read. There are situations when, especially with sufficient comments, that a little bit of nesting will help separate the cases logically, so we don't want to enforce a blanket ban on the practice.
Don't return #t and #f in an if statement! This one bugs a lot of experienced Scheme programmers for good reason: it makes it harder for them to read the program. For example, rather than:

(if (funny? sent) #t #f)

simply do this:

(funny? sent)

And, don't forget to use the not statement if you find yourself needing to reverse the order of the #t and #f statements. (E.g., in the example above, if you're testing if something is not funny).
Use proper indenting. Making sure your indenting follows the program flow can make the difference between a readable program and an unreadable one. Emacs, and other scheme editors, can automatically re-indent a range of source code for you. Use this feature!
None of this should be new to you! Be sure to discuss anything you are unsure about with your TA. Your reader contains a document titled Coding Conventions (also available here) which discusses some of these issues in more detail.
30.1.3 (Display page) Miniproject 3 submission details
A solution to this project, involving the files winner.scm and winner-tests.scm, is due at 11:59pm on Thursday, July 24th. To submit, put your files in a directory named mp3 and submit them in the usual manner (i.e., by typing submit mp3 via unix). You may, but need not, work in a partnership of two on this project; you and your partner should be in the same lab section. Both partners will receive the same score on the project. If you work with a partner:

Make sure only one partner submit the files.

Put both your names in a comment at the top of winner.scm.

Include description inside the file winner.README that describes how each partner contributed to the project. Put the file inside the mp3 directory, and submit it with your other files.