Exercise 1 Consider the following data definition:

; A Transaction is one of:

; - (list "DEPOSIT" String PositiveNumber)

; - (list "WITHDRAWAL" String PositiveNumber)

; INTERPRETATION: A transaction is either a deposit (with a

; String describing the source and an amount in dollars) or a

; withdrawal (with a String describing the destination and an

; amount in dollars).

; A BankAccount is a [List-of Transaction]

; INTERPRETATION: The list of transactions in a user's account.

Design the function account-balance that accepts a BankAccount and returns a Number representing the current balance. If more money has been withdrawn than deposited, the Number should be negative. For example,

(check-expect (account-balance (list (list "DEPOSIT" "paycheck" 965.01)

(list "WITHDRAWL" "dinner" 100)))

865.01)

Stage 1 – New communications data definitions:

In fact, it can be even more general than the protocol we’re using here; see The Poetry of S-Expressions for more information.

When a big-bang handler creates a make-package, the message being sent to the server can be more general than a mere string. For this stage of the project, we will use the following definition:

; A ClientMsg is one of

; - "CATCHUP"

; - (list "POST" String)

; - (list "REPLY" Natural String)

; INTERPRETATION:

; – Sending the message "CATCHUP" tells the server you would like it

;    to send you all the prior posts the server has received.  You are only

;    allowed to ask the server for catch-up messages once; a second request

;    will result in an error.

; – Sending the message (list "POST" String) – i.e., a two-item

;    list whose first item is the string "POST", and whose second item is a

;    String – indicates you are writing a new post, where the string provides

;    the text of the post

; – Sending the message (list "REPLY" Natural String) indicates that

;    you are replying to an existing post (Note: you cannot reply to a reply).

;    The number indicates the post's id, and the string is the text of the post.

When your on-key handlers send a make-package to the server, they will send a ClientMsg. If you send anything that does not match this format, the server will send you an error response. Of course, the server can’t just send back flat strings any longer, because it has more information for you too:

; A ServerMsg is one of:

; - (list "POST" Natural String String)

; - (list "REPLY" Natural String String)

; - (list "ERROR" String)

; INTERPRETATION:

; – Receiving a "POST" message means there is a new post with the given ID#,

;    author, and contents.  This is the same

;    information as you've been receiving via "id:author:contents", except

;    that the data is properly broken apart for you, instead of mashed into

;    one string.

; – Receiving a "REPLY" message there is a new reply containing the ID# of

;    the parent post (that this is a reply to), the author of the reply as

;    the next string, and whose content is the final string.

; – Receiving an "ERROR" message means the client made a mistake, with the

;    error message given as the string.

Your on-receive handler now needs to process a ServerMsg instead of merely a string.

Change your existing functions so that they handle these new data definitions, by sending or receiving "POST" messages and "ERROR" messages. Ignore the other message types for now.

Hint: Work through the templates for these data definitions as carefully as you can. While these definitions use list, they are not lists of anything (in the sense of [List-of anything]) – they are fixed size, with specific elements at specific places. To distinguish the cases of these data definitions, you can’t use empty? and cons?; instead, since you are guaranteed that the lists won’t be empty, you can use other predicates on the first of the list to distinguish the cases.

Hint: You will not be using the standard list template to process this data, nor will you be using list abstractions. Think of these more like structures, where you use the functions first, second, third, and fourth to access the pieces.

MILESTONE: At this point, if you start your program, it should behave identically to Assignment 7a.

Stage 2 – New client data definitions: Now that you have more information about posts and their replies, you’ll need to keep track of the distinction between them. In the previous assignment, we said a History was a [List-of String], where each string was an individual post. This will no longer suffice. Instead, refine your definitions:

The definition for Post seems strange: why bother pulling the id number of a post out of the structure, and making these weird not-quite-lists? The goal is actually to make the History structure easier to use, and the list helper function assoc will wind up working quite well with this definition in future assignments.

; A History is a [List-of Post]

; INTERPRETATION: the history of top-level posts seen so far.

; A Post is a (list Number (make-post ??????????))

(define-struct post [??????????])

; INTERPRETATION: The ID# of a post, as well as .....?

; A Reply is a (make-reply ?????????)

(define-struct reply [????????])

; INTERPRETATION: .....?

A History is a list of top-level posts. Each Post keeps track of who wrote it and what it says, and contains a unique ID#. Each post also keeps track of the list of its replies. Each Reply just keeps track of its author and content.

The "REPLY" messages above send an ID# with the reply, so that you can find the Post that this reply belongs to. Once you’ve found that (which you will do in the next assignment), the Reply no longer needs to track that information.

Complete the definitions of Post and Reply, so that Posts keep track of their ids, authors, contents, and the list of Replys that have been seen so far, and a Reply keeps track of its author and contents.

Hint: At this point, since a user of your program has no way to create Replys, what default value should your Posts contain for their list of replies so far?

MILESTONE: At this point, your program will again behave identically to Assignment 7a, but it will be prepared for further extension.