Science Computer 15-212, Spring 2009 Assignment 4 DUE: Wednesday, March 25, 2009, 2:12 A.M.
REMINDER: Due Tuesday night / early Wednesday morning.
[Maximum points: 100]
Handin instructions
Put your SML code into a le named hw4.sml. We have provided a template hw4.sml o the assignment webpage, which you should copy, then edit. All of your denitions and comments should be in your version of hw4.sml. The TAs will not look at any other les in your hw4 directory. Once you have nished the assignment, please copy your nal version of this le to your hw4 handin directory. Your hw4 handin directory is /afs/andrew/course/15/212sp/handin/your-Andrew-ID/hw4/ Please type your name, userid, and your recitation instructors name in a comment at the top of your le.
Guidelines
You should only use the functional aspects of SML. Your code should contain no mutation or imperative constructs. Also, do not use = to compare values of a non-equality type. Be sure to comment your code (all exercises) as described in class. Strive for elegance! Not every program which runs deserves full credit. Make sure to state invariants in comments which are sometimes implicit in the informal presentation of an exercise. If auxiliary functions are required, describe concisely what they implement. Do not reinvent wheels. Do try to make your functions small and easy to understand. Use tasteful layout and avoid longwinded and contorted code. None of the problems requires a very large number of lines of SML code. Make sure that your entire le compiles and runs. If you are unable to complete portions of the assignment, comment out the part of the code that does not work properly, and explain what you did, what worked, and what didnt. It is your responsibility to explain as carefully as you can why you think you were unable to get the code working, what you think is wrong, and how you might go about xing it. The quality of such an explanation will be important to us in deciding whether to give you partial credit. WARNING: If your le is not named hw4.sml (all lowercase), or if the le does not load, or if your function types do not match our specs, you will lose 50 points. E.g., a misnamed le that is otherwise perfect will receive a score of 50. Homeworks must be all your own work. Read the policy on cheating in the syllabus. Late homeworks will be accepted only until the start of lecture on Thursday, with a 25% penalty. See the syllabus for the complete policy on late assignments. If you have questions with this lab, contact Justin Hurley ([e-mail]) or use the newsgroup academic.cs.15-212.discuss
1
Introduction
The purpose of this assignment is to further familiarize you with SMLs module system. You have already seen signatures and structures; in this assignment we will also be using functors. A functor is a function from modules to modules. That is, a functor is a function that may take structures as arguments and that, when applied, produces a structure as its result. In this way, we can dene polymorphic modules (the functors) that can be instantiated (by evaluating the functor on its arguments) to deal with particular data types. We will illustrate the use of functors in creating structures which represent series of events. Our implementation can be used to represent any set of ordered events. For example, we could represent driving to Giant Eagle as the series of events: START("CMU"), STRAIGHT(1.2), RIGHT, STRAIGHT(0.2), END("Giant Eagle"). In this assignment, we will rst use our implementation to represent wins and losses. Finally we will represent music as a series of chords. Lets get started!
Problem 1 : Series (50 Points)
Series represent a set of ordered events. In other words, the events in a series make sense when viewed sequentially. Two series are equal if they have the same events in the same order. We require that each event can be compared for equality and can be represented as a string. To satisfy this we encapsulate each event in a structure ascribing to the EVENT signature. Observe that the signature requires a distinguished nonevent event, which will be useful for representing the lack of any event at a particular time. The EVENT signature is dened as follows: signature EVENT = sig type t (* parameter *) val nonevent : t val equal : t * t -> bool val toString : t -> string end Our representation of series can only allow event types which have a corresponding structure ascribing to EVENT. In order to enforce this provision while still maintaining generality, we will dene our series using functors. Our series functors will take a structure ascribing to EVENT as an argument and produce a structure that ascribes to the SERIES signature, which is dened as follows:
2
signature SERIES = sig type event (* Parameter *) type series (* Abstract type *) val empty : series val val val val val val val val val val val val val val val val end fromList toList hd tl toString map map2 foldl foldr length equal sub indexOf subseries cons append : : : : : : : : : : : : : : : : event list -> series series -> event list series -> event series -> series series -> string (event -> event) -> series -> series (event * event -> event) -> (series * series) -> series (event * b -> b) -> b -> series -> b (event * b -> b) -> b -> series -> b series -> int series * series -> bool series * int -> event event * int -> series -> int option int * int -> series -> series event * series -> series series * series -> series
Here is a description of each function: fromList l takes a list of events l and converts it into a series. toList s takes a series s and returns a list of events that represents s. hd s returns the rst event in s. This function may raise exception Empty, just like the corresponding List function might. tl s returns s with the rst event removed. This function may raise exception Empty. toString s creates a representation of the series s using SMLs built-in string type. map f s maps the function f over the corresponding events in the series s and returns the resulting series. map2 f (s1, s2) maps the function f over the events in the pair of series s1 and s2 and returns the resulting series. If one series is longer than the other, it ignores the trailing events in the longer series. foldl f b s folds the function f over the series s, starting from the left. foldr f b s folds the function f over the series s, starting from the right. length s returns the number of events in the series s. 3
equal (s1, s2) tests the two series for equality. sub (s, n) returns the nth event in s (using zero-based indexing). If n is greater than or equal to the length of s, it raises Subscript. indexOf (c, n) s searches the series s beginning at index n for the rst occurrence of the event c. It returns an option indicating the index of this occurrence, if any. subseries (start, len) s returns a subseries of the series s with a length of len beginning at index start. If start is greater than or equal to the length of s it returns the empty series. If there are fewer than len events in s beginning at start, it returns the subseries from start to the end of s. cons (c, s) returns a series representing the event c prepended to the series s. append (s1, s2) returns a series representing the concatenation of the series s1 and s2. Notice that the SERIES signature includes a number of functions that can be used to operate directly on series (e.g., map, map2, foldl, and foldr). Also, be sure to write the abstraction function and representational invariants for each implementation.
1.1 The ListSeries Functor (15 Points)
There are many ways that a series can be implemented. Because a series has many similarities to a list, we will rst implement a series as a list of events. Create the ListSeries functor, which, given a structure to represent events, returns a structure which ascribes to the SERIES signature. ListSeries should represent a series as a simple list of events. functor ListSeries (structure Event : EVENT) :> SERIES where (* you fill in *) = struct ... end As explained above, the type series should be implemented as: type series = event list
1.2 The CompactSeries Functor (20 Points)
Although implementing a series using a list is intuitive, it is not necessarily the best way of implementing a series. As we will see in the next problem, there are many types of series which might contain large, consecutive blocks of the same event. Implementing a real compression algorithm would be beyond the scope of this course, however the CompactSeries can eciently store series with many repeating events.
4
With this in mind, create the CompactSeries functor, which, given a structure to represent events, returns a structure which ascribes to SERIES. CompactSeries should represent series as lists of (event * int) pairs where each such pair (c, n) represents a block of n events which each have the value c. You should observe the invariants that n is always greater than zero and that no two adjacent blocks have the same value for c. functor CompactSeries (structure Event : EVENT) :> SERIES where (* you fill in *) = struct ... end The type series should be implemented as type series = (event * int) list as explained above.
5
1.3 Win Some, Lose Some (10 Points)
To begin, we will use our Series from above to represent the outcomes of sporting events (for example an NFL game or a college basketball game). In our rst implementation we will simply store wins and losses. Our second implementation will also include the score. (a) First bind one of your functors to the identier Series as shown: functor Series = CompactSeries (* For example. How else can this be done? *)
(b) For this part we will store wins and losses using the datatype simple outcome. datatype simple outcome = WIN | LOSS | NOGAME Implement a structure SimpleOutcome which ascribes to the EVENT signature and represents wins and losses using the provided simple outcome type. The constructor NOGAME should correspond to the nonevent event. As a string, a win should be represented by "W", a loss by "L", and NOGAME by the empty string "". structure SimpleOutcome :> EVENT where (* you fill *) in = struct ... end Now, implement the structure SimpleOutcomeSeries using Series and ascribing to the signature SIMPLEOUTCOME SERIES as given below. It is important that you do not reference ListSeries or CompactSeries directly so that we can properly test your code. Use the SimpleOutcome structure that you implemented above. signature SIMPLEOUTCOME SERIES = SERIES where (* you fill in *) (c) Now, we will implement a similar structure Outcome. SimpleOutcome only specied whether a team won or lost. Outcome species whether a team won or lost and the score of the game. As a string, an outcome is represented as a "W" or "L" and the score. For example, "W 87-72" or "L 58-64". Use the provided outcome datatype: datatype outcome = WIN of (int * int) | LOSS of (int * int) | NOGAME Complete the Outcome structure: structure Outcome :> EVENT where (* you fill in *) = struct ... end Now, implement the structure OutcomeSeries using Series and ascribing to the signature OUTCOME SERIES as given below. signature OUTCOME SERIES = SERIES where (* you fill in *) 6
1.4 Thought Question (5 Points)
(a) Our implementation of outcomes can represent a variety of sports scores (football, soccer, basketball, etc...). Assume we are representing college basketball scores. For example, for Duke basketball this season we have the following outcomes. DATE 11/10 11/11 11/16 11/20 11/21 11/23 11/28 12/02 12/06 12/17 12/20 12/31 1/04 1/07 OPPONENT PRSB GSU URI vs. SIU vs. MICH UM DUQ @ PU @ MICH UNCA vs. XAV L-MD VT DAV RESULT W 80-49 W 97-54 W 82-79 W 83-58 W 71-56 W 78-58 W 95-72 W 76-60 L 81-73 W 99-56 W 82-64 W 92-51 W 69-44 W 79-67 DATE 1/10 1/14 1/17 1/20 1/24 1/28 2/01 2/04 2/07 2/11 2/15 2/19 2/22 3/08 OPPONENT @ FSU @ GT GU NCST MARY @ WFU UVA @ CLEM MIA UNC @ BC @ SJU WFU @ UNC RESULT W 66-58 W 70-56 W 76-67 W 73-56 W 85-44 L 70-68 W 79-54 L 74-47 W 78-75 L 101-87 L 80-74 W 76-69 W 101-91 W 102-86
If we are representing Dukes season with a series of SimpleOutcomes, which is more ecient: ListSeries or CompactSeries? Likewise, if we are using a series of Outcomes, which is more ecient? Explain. (b) Suppose we had written the Outcome structure without the where clause, as shown below: structure Outcome :> EVENT = struct ... end Explain why this wouldnt let us use the Outcome structure as intended.
7
Problem 2 : Tokenizer (15 Points)
The SERIES signature declares a number of very useful functions for working with series. Unfortunately, we must reimplement each of those functions whenever we write a new SERIES implementation. Thus, it is undesirable to include every function we could possibly need in the SERIES signature. Instead, since we have a fairly complete set of tools for working with series, we can use these functions to manipulate series without having any knowledge of their underlying implementation. One such operation that we might wish to perform on series is tokenization, which refers to the process of breaking a series into a list of series (called tokens) by dividing it along boundaries which are marked by delimiter events. For example, with our series of outcomes we could use losses as delimiters to get a set of all winning streaks. You will create the SeriesTokenizer functor which takes a structure ascribing to SERIES as input and returns a structure ascribing to SERIES TOKENIZER. This is a simple signature which is dened as follows: signature SERIES TOKENIZER = sig type event (* parameter *) type series (* parameter *) val tokenize : (event -> bool) -> series -> series list end It contains only a single function tokenize which takes a delimiter function and a series. The delimiter function takes an event as input and returns true if and only if that event is a delimiter. So for our previous example, to split a series of simple outcomes into winning streaks, we might use a delimiter function such as: fn c => (c = LOSS) Note that the output of the tokenize function should never contain any delimiter events; they should all be removed. Also, tokenize should not return any empty tokens, even if there are two adjacent delimiter events in the input series. In our example, if we were to tokenize the series which represents the outcomes W, L, L, W, W, W, L using the delimiter function dened above, we would get a list of series which represents the following list of outcomes: [W, WWW]
8
Problem 3 : Music (35 Points)
Series can be applied to more complicated data than the outcomes of sports games. For this problem we will represent music using series. First, we will represent typical sta music (such as that used for a keyboard) using series. Second, we will represent guitar tabs as series. Implementing both of these stresses not only the exibility of our series implementation, but also the exibility of SMLs module system.
3.1 Chords (10 Points)
A (very) brief introduction to musical notes: the range of musical pitches is divided into octaves, each of which contains twelve semitones. The semitones are named as in the tone datatype below, where sh stands for sharp. So, a note can be identied by which octave its in, and which semitone within that octave. So, for example, (A,4),(Ash,4),(B,4),(C,5),(Csh,5) is a series of notes each one semitone higher than the previous. First, implement keyboard chords as the structure KChord ascribing to the signature EVENT. You should represent keyboard notes and chords using the following types. In particular, a keyboard chord is either a rest or a list of notes, each of which consists of a tone and an octave. type octave = int datatype tone = C | Csh | D | Dsh | E | F | Fsh | G | Gsh | A | Ash | B type k note = tone * octave datatype k chord = CHORD of k note list | K REST structure KChord :> EVENT where (* you fill in *) struct ... end You will need to write a (fairly straightforward) toString function. For reference, here are some sample strings representing two chords and a rest: "[(G,4)]", "[(A,4),(B,5),(Csh,5)]", and "REST". You will also need to implement the nonevent value of EVENT. That is simply a keyboard rest.
Next, implement a guitar tab (guitar chord) as the structure ...