Problem Set 1

home work!

Topic Basic Programming

Due Friday, January 22, 2016 at 1pm

Purpose The goal of this problem set is to demonstrate basic competence in the prerequisites of this course and the PhD program in general, namely, solid programming skills in any programming language.

The problem also sets up a problem domain with a domain-specific language (DSL). This time around you write an "interpreter" for a program in the language. Later you will learn how to check basic properties and how to model this DSL in the tools that the course provides.

image

Problem 1 Write a one-page description of your chosen programming language X and why it is your favorite. Consider one or all of the following topics:
  • programming language X has a [your adjective here] syntax,

  • programming language X has a [your adjective here] type system,

  • programming language X has a [your adjective here] pragmatics,

  • programming language X has a [your adjective here] tool suite,

  • programming language X is well-suited for Y applications.

Do not feel restricted to these attributes. If you consider another one the prime reason, use it to illustrate X’s power.

Imagine writing this memo for a manager in a development lab.

Be concise. Use active voice and descriptive verbs. Avoid subjective adjectives; instead bring across your preference through the technical description. Keep in mind that the addressee may check up on the facts that you present to support your claim. (Also, see the advice on memo1 provided on the Writing page.)

To format the memo, use (1) an 11-point font, (2) 1.5in margins all around, (3) a header that specifies the paper title and the author(s) of the memo.

Deliverable Print your memo and put it in my mailbox in 202 WVH. I will mark it up for basic English problems. I will schedule times to meet with you on January 27th (3:45-5pm) to give you feedback. Then include a revised PDF version of the memo in the submission of problem set 3.

Problem 2 Your task is to design a program that performs a simplified flight search given data on airports and flights, along with a flight query. The program reads a flight-search configuration from the (Unix) standard input, and it writes its solution to the standard output. It produces a single flight plan from the origin to the destination, subject to some constraints (explained below).

A flight-search configuration specifies two pieces: data on airports, including all departing flights, and a flight query that includes an origin, a destination, and what airline to restrict the search to. An airport comes with an airport code (e.g., BOS), a name (e.g., Boston Logan), and a series of outgoing flights. Each flight specifies the two-character airline code (e.g., UA for United Airlines), the flight number, and the code for the airport to which the flight is headed.

The program produces a flight plan which is a list of flight segments that would get one from the specified origin to the destination using only flights on the specified airline. Each flight segment specifies the departure and arrival airport codes and the flight number (e.g., BOS ORD 139). The flight plan must not include any cycles. If airport PQR has multiple (direct) flights to airport XYZ run by the airline AL specified in the query, then the first of these should be chosen for the output flight plan. Furthermore, if airport PQR has (direct) flights on airline AL to different airports UVW, XYZ, etc., listed in that order, then a flight plan connecting through UVW should be given preference---but if one does not exist, then a flight plan connecting through XYZ, and so on.

The flight-search configuration is specified using an XML-based domain-specific language, dubbed FSL. Here is the grammar of FSL:

  FSConfig = <flightsearch origin=String destination=String airline=AirlineCode>

              Airport ...

             </flightsearch>

  Airport =  <airport code=String name=String>

              Flight ...

             </airport>

  Flight =   <flight airline=String flightnum=String to=String />

  AirlineCode is a String

The origin and destination attributes of a flightsearch specify airport codes for the flight query while airline specifies a two-character airline code for the airline the passenger wishes to fly. An airport element provides the airport code and its name; its content lists any flights to other airports. Finally, a flight element specifies the airline code, flight number, and the airport code for the flight’s destination.

In this grammar, the dots (...) denote a possibly empty sequence of XML elements. Hence, an FSConfig might not specify any airports, and an Airport might not include any flights.

Below are two examples of flight-search configurations and what the program is expected to produce.

input

   

expected output

<flightsearch origin="ORD" destination="PDX"

              airline="DL">

  <airport code="BOS" name="Boston Logan">

    <flight airline="UA" flightnum="139" to="ORD" />

    <flight airline="DL" flightnum="211" to="PDX" />

    <flight airline="DL" flightnum="441" to="ORD" />

  </airport>

  <airport code="ORD" name="Chicago O'Hare">

    <flight airline="UA" flightnum="138" to="BOS" />

    <flight airline="DL" flightnum="440" to="BOS" />

  </airport>

  <airport code="PDX" name="Portland International">

    <flight airline="DL" flightnum="212" to="BOS" />

  </airport>

</flightsearch>

   

ORD BOS 440

BOS PDX 211

The output means that from the origin, ORD, one can take flight DL 440 to BOS, then take flight DL 211 to the destination PDX. Note that all flights in the output use DL (Delta Airlines) as required by the query.

Next, consider the same flight search again, except on a different airline (UA):

input

   

expected output

<flightsearch origin="ORD" destination="PDX"

              airline="UA">

  <airport code="BOS" name="Boston Logan">

    <flight airline="UA" flightnum="139" to="ORD" />

    <flight airline="DL" flightnum="211" to="PDX" />

    <flight airline="DL" flightnum="441" to="ORD" />

  </airport>

  <airport code="ORD" name="Chicago O'Hare">

    <flight airline="UA" flightnum="138" to="BOS" />

    <flight airline="DL" flightnum="440" to="BOS" />

  </airport>

  <airport code="PDX" name="Portland International">

    <flight airline="DL" flightnum="212" to="BOS" />

  </airport>

</flightsearch>

   

No flights found

This time, since there is no valid flight plan from the origin, ORD, to the destination, PDX, on the specified airline (UA), the program outputs: No flights found

Deliverable Email a tar.gz bundle to my CCS email address whose name combines the last names of the pair in alphabetical order. The tar bundle must contain a single directory—with the same name as the tar ball—with a README.txt file and an executable file 1.xyz (for your choice of extension).

The README.txt file must start with the following lines:

  ;; NameOfPartner1, NameOfPartner2

  ;; email@of.partner1.com, email@of.partner2.org

When we unpack the bundle on the standard departmental LINUX boxes (login-linux is a good example), we expect to cd into this directory and run the solution as

  $ ./1.xyz < 1-example1.xml | diff - 1-output1.txt

where 1-example1.xml and 1-output1.txt are files we will supply.