这是一个美国的关于项目报告卡的Haskell代写

1 Introduction

Provide a brief summary and some background of the project. How would it be useful? What implementations

do currently exist? What are their strengths and limitations?

2 Users

How is the project going to be used, and what specififically is it used for? What kind of users are affffected by

the project and in which way? What is known or can be reasonably assumed about the (technical/domain)

background of users? (Usually, it is safe to assume that users are experts in the domain of the project.)

Also, explain the limitations of the project. What features is not covered, and what cannot be done with

(If difffferent kinds of users are involved, what are there limitations of for the difffferent user groups?)

3 Outcomes

What is (are) the imput(s) and outcome(s) or resulting values of executing your program? Note that, in

general, a program can produce a variety of results. Consider, for example, a program for describing

vacation plans (including alternatives). We can imagine that a vacation plan can be analyzed to yield a

set of date/time ranges for the vacation (based on the availability of flflights, hotels, etc.), or a set of cost

estimates (based on travel and date options). Moreover, we can imagine deriving to-do lists from the travel

plan (making reservations, buying tickets, etc.) or entertainment suggestions (parks, museums, events, etc.).

The outcomes should be made more precise in Section ?? in the form of function signatures once the

basic objects and operations have been identifified in Sections 6 and 7, respectively.

4 Use Cases / Scenarios

Describe several typical example problems or use cases that can be addressed by your program. For each

example, give a summary of what the example is about, and explain how important and representative it is

for the domain.

Then describe in more detail the steps involved in solving the problem (either by hand or with existing

tools). This process can be very helpful in shedding light on what kind of basic objects, types, and operations

are required.

The fifinal version of this section should contain a trivial example that illustrates the basic structure of your

program as well as a bigger example that demonstrates the full scope of your project. The bigger example

allows a reader to judge the scope and impact of your project and whether it would be useful to them.

It is very important to clearly describe and distinguish between the inputs and outputs of your program.

Note that some projects present their functionality in the form of several difffferent functions with difffferent

inputs and outputs.

5 Implementation Language

This section is optional.

If you are not using Haskell, brieflfly say what (functional) language you use (Elm, ML, Idris, OCaml, Scheme,

…) to implement your project, and why. What features of the language are important for your implementation

that Haskell lacks?

6 Basic Objects

What are the basic objects that are manipulated and used by your program? Basic objects are those that are

not composed out of other objects.

As a general rule, the fewer basic objects one needs, the better, because the resulting design will be more

concise and elegant. The basic objects should be described by a set of Haskell type and data defifinitions.

Use the program environment to show code, as illustrated below.

type Point = (Int,Int)

Show how (some (parts) of) the examples from Section 4 will be represented by values of the envisioned

types. For example:

home :: Point

home = (10,13)

Also, list current limitations that you expect in a future iterations to overcome.

Be prepared to revise this section many times!

7 Operators and Combinators

Identify operators that either transform objects into one another or build more complex objects out of simpler

ones. Depending on what implementation or form of embedding will be chosen, operators may be given as

constructors of data types or functions.

Combinators are higher-order functions that encode control structures specifific to your project. The

function map is a combinator that realizes a looping construct for lists. The operations of the parser

library Parsec are called parser combinators, since parsers themselves are represented as functions. The

identifification of the right set of combinators is a key step in the design of an elegant functional program.

With basic objects, operators, and combinators, you should be able to demonstrate how the examples

from Section 4 can be represented. All limitations encountered here should be classifified as either:

(1) Temporary

(2) Fundamental

Temporary limitations should be noted in this section and in Section 6 as TO DO items for future revisions

of the design. Fundamental limitations should be reported and listed in detail in Section 2.

Be prepared to revise this section many times!

8 Implementation Strategy and Design Evolution

This section is optional. Include this section only if you have something interesting to say.

You may want to discuss alternative representations, their advantages and disadvantages, and why you

chose a particular representation for your project. Keeping track of the evolution of your representation can

sometimes be helpful in giving you confifidence in your design decisions.

As you iterate over difffferent designs of your DSL, it is quite instructive to document some of the old,

obsolete designs, that is, show the type defifinitions and function signatures, explain why this design seemed

attractive at fifirst and then what motivated you to change it.

This part may seem like an unnecessary burden to you, but it helps you and others to understand your

current design, and it probably answers questions that users (or reviewers) of the project might have about

the design, because they may have thought of your initial design also and are wondering why it has not been

adopted.

9 Related DSLs

Try to fifind similar projects to the one described here and compare them with your implementation. Projects

with the same or slightly difffferent outcomes help you refifine the design of the project requirements described

in Sections 2 and 3.

These related projects can be part of your in-class presentation.

10 Future Work

This section is optional. Include this section only if you have something interesting to say.

A speculation about what it takes to remove some of the limitations and whether it seems worth the effffort.

References

List references to similar projects identifified in Section 9 and potentially other related work.