6.10

Assignment 8b

home work!

Programming Language ISL

Due Date: Thursday Monday (10/30) at 9:00pm (Week 8)

Purpose To practice refactoring programs and refining data definitions.

Finger Exercises

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)

Exercise 2 Design the function within-distance-of-origin. It should accept a [List-of Posn] and PositiveNumber, and return a Number representing the count of Posns whose Euclidean distance from the origin is less than the given number.

Forum Exercises – Summary

NOTE: Because the message protocol of your Forum client is changing, you’ll need to connect to a different port on the server. Make sure you change your big-bang to connect to ports between 10006 – 10010. (We will maintain the old ports for the older versions of your code to use, if you want to debug your prior homeworks.)

Here’s a summary of the changes in this assignment. More detail can be found below.

Stage 1 – New communications data definitions: Instead of sending strings to the server, send values from the following data definition:

; A ClientMsg is one of
; - "CATCHUP"                     <<== ask server to send old posts
; - (list "POST" String)          <<== create new post with given text
; - (list "REPLY" Natural String) <<== reply to post with this id, and given text

When receiving messages from the server, expect to receive messages of the following form:
; A ServerMsg is one of:
; - (list "POST" Natural String String)  <<== new post (id, author, content)
; - (list "REPLY" Natural String String) <<== new reply (post id, author, content)
; - (list "ERROR" String)                <<== something went wrong

Stage 2 – New client data definitions: Revise your definitions of History to the following, and complete the following data definitions:

; 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 [??????????])
 
; A Reply is a (make-reply ?????????)
(define-struct reply [????????])

Forum Exercises – More details

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.