COMP2209 Assignment Instructions

Learning Outcomes (LOs)

 Understand the concept of functional programming and be able to write programs in this style,

 Reason about evaluation mechanisms.

Introduction

This assignment asks you to tackle some functional programming challenges to further improve your

functional programming skills. Four of these challenges are associated with interpreting, translating,

analysing and parsing a variation of the lambda calculus. It is hoped these challenges will give you

additional insights into the mechanisms used to implement functional languages, as well as

practising some advanced functional programming techniques such as pattern matching over

recursive data types, complex recursion, and the use of monads in parsing. Your solutions need not

be much longer than a page or two, but more thought is required than with previous Haskell

programming tasks you have worked on. There are three parts to this coursework and each of them

has two challenges. Each part can be solved independently of the others and they are of varying

difficulty, thus, it is recommended that you attempt them in the order that you find easiest.

For ease of comprehension, the examples in these instructions are given in a human readable format

you may wish to code these as tests in Haskell. To assist with a semi-automated assessment of this

coursework we will provide a file called Challenges.hs. This contains Haskell code with signatures for

the methods that you are asked to develop and submit. You should edit and submit this file to

incorporate the code you have developed as solutions. However, feel free to take advantage of

Haskell development tools such as Stack or Cabal as you wish. You may and indeed should define

auxiliary or helper functions to ensure your code is easy to read and understand. You must not,

however, change the signatures of the functions that are exported for testing in Challenges.hs.

Likewise, you may not add any third-party import statements, so that you may only import modules

from the standard Haskell distribution. If you make such changes, your code may fail to compile on

the server used for automatic marking, and you will lose a significant number of marks.

There will be no published test cases for this coursework beyond the simple examples given here - as

part of the development we expect you to develop your own test cases and report on them. We will

apply our own testing code as part of the marking process. To prevent anyone from gaining

advantage from special case code, this test suite will only be published after all marking has been

completed.

It is your responsibility to adhere to the instructions specifying the behaviour of each function, and

your work will not receive full marks if you fail to do so. Your code will be tested only on values

satisfying the assumptions stated in the description of each challenge, so you can implement any

error handling you wish, including none at all. Where the specification allows more than one

possible result, any such result will be accepted. When applying our tests for marking it is possible

Module: Programming III Examiners

:

Julian Rathke,

Nick Gibbins

Assignment: Haskell Programming Challenges Effort: 30 to 60 hours

Deadline: 16:00 on 11/1/2024 Feedback: 2/2/2024 Weighting: 40%

your code will run out of space or time. A solution which fails to complete a test suite for one

exercise within 15 seconds on the test server will be deemed to have failed that exercise and will

only be eligible for partial credit. Any reasonably efficient solution should take significantly less time

than this to terminate on the actual test data that will be supplied.

Depending on your proficiency with functional programming, the time required for you to implement

and test your code is expected to be 5 to 10 hours per challenge. If you are spending much longer

than this, you are advised to consult the teaching team for advice on coding practices.

Note that this assignment involves slightly more challenging programming compared to the previous

functional programming exercises. You may benefit, therefore, from the following advice on

debugging and testing Haskell code:

https://wiki.haskell.org/Debugging

https://www.quora.com/How-do-Haskell-programmers-debug

http://book.realworldhaskell.org/read/testing-and-quality-assurance.html

It is possible you will find samples of code on the web providing similar behaviour to these

challenges. Within reason, you may incorporate, adapt and extend such code in your own

implementation. Warning: where you make use of code from elsewhere, you must acknowledge and

cite the source(s) both in your code and in the bibliography of your report. Note also that you

cannot expect to gain full credit for code you did not write yourself, and that it remains your

responsibility to ensure the correctness of your solution with respect to these instructions.

The Challenges

Part I  C Circuit Puzzles

In these two challenges we will introduce a type of circuit puzzle in which the solver is presented

with a grid of "tiles" each with "wires" printed on them. The solver is then expected to rotate each

tile in the grid so that all of the wires connect together to form a complete circuit. Moreover, each

puzzle will contain at least one tile that is a "source" tile for the circuit, and at least one tile that is a

"sink" tile. A completed circuit will ensure that every sink is reachable from a source and vice-versa.

There may however be multiple sources and multiple sinks.

The grid may be of any rectangular size and will be given as a list of non-empty lists of Tile values. A

Tile value is value of the data type given by:

data Edge = North | East | South | West deriving (Eq,Ord,Show,Read)

data Tile = Source [ Edge ] | Sink [ Edge ] | Wire [ Edge ] deriving (Eq,Show,Read)

type Puzzle = [ [ Tile ] ]

where a Tile simply lists which of its edges offer connection of wires. The Source and Sink tiles must

contain at least one connector edge and Wire tiles must contain either zero (an empty Tile) or at

least two connector edges. Duplicate entries in the edges list are ignored and order does not matter.

Connector edges are considered to connect across two Tiles if they share a connector edge. For

example, a Tile offering a West connector placed to the right of a Tile offering an East connector

would have a connecting wire. A Wire Tile is connected if all of its connector edges are connected.

Similarly Source and Sink tiles are connected if, all of their connector edges are connected.

Example tiles are as follows :

Source [ West ] could be represented visually as

Sink [ North, West ] could be represented visually as

Wire [ East, South ] could be represented visually as

and finally

Wire [ North, East , West ] could be represented visually as

An example 3x3 puzzle is given below followed by a visual representation of the puzzle:

[ [ Wire [North,West] , Wire [North,South] , Source [North] ],

[ Wire [North,West], Wire [East,West], Wire [North,East] ],

[ Sink [West] , Wire [North,South] , Wire [North,West] ] ]

The following image shows a solution to the above puzzle obtained by rotating each of the Tiles.

Note the completed circuit in the solution.

Challenge 1: Completedness of circuits.

The first challenge requires you to define a function

isPuzzleComplete :: Puzzle -> Bool

that, given a list of list of tiles, simply returns whether the puzzle is completed. That is, this function

returns True if and only if all Tiles are connected, for every Source tile, there exists a path following

the wires to at least one Sink tile and for every Sink tile, there is a path following the wires to at least

one Source tile.

Challenge 2: Solve a Circuit Puzzle

This challenge requires you to define a function

solveCircuit :: Puzzle -> Maybe [ [ Rotation ] ]

where data Rotation = R0 | R** | R180 | R270 deriving (Eq,Show,Read)

This function should, given a circuit puzzle, return Just of a grid of rotations such that, if the rotations

were applied to the corresponding Tile in the input grid, the resulting Puzzle will be a completed

circuit. Where this is not possible, the function should return the Nothing value.

The values of Rotation represent

 R0 no rotation

 R** rotate Tile clockwise ** degrees around the centre of the tile

 R180 rotate Tile clockwise 180 degrees around the centre of the tile

 R270 rotate Tile clockwise 270 degrees around the centre of the tile

For example,

solveCircuit [ [ Wire [North,West] , Wire [North,South] , Source [North] ], [ Wire [North,West], Wire

[East,West], Wire [North,East] ], [ Sink [West] , Wire [North,South] , Wire [North,West] ] ]

could return

Just [[R180,R**,R270],[R**,R0,R180],[R180,R**,R0]]

note that this solution is not unique.

Part II  C Parsing and Printing

You should start by reviewing the material on the lambda calculus given in the lectures. You may

also review the Wikipedia article, https://en.wikipedia.org/wiki/Lambda_calculus, or Selinger's

notes http://www.mscs.dal.ca/~selinger/papers/papers/lambdanotes.pdf, or both.

For the remaining challenges we will be working with a variant of the Lambda calculus that support

let-blocks, discard binders and pairing. We call this variant Let_x and the BNF grammar for this

language is as follows

Expr ::= Var | Expr Expr | "let" Eqn "in" Expr | "(" Expr ")"

| "(" Expr "," Expr ")" | "fst" "("Expr")" | "snd" "("Expr")" | "\" VarList "->" Expr

Eqn ::= VarList "=" Expr

VarList ::= VarB | VarB VarList

VarB ::= "x" Digits | "_"

Var ::= "x" Digits

Digits ::= Digit | Digit Digits

Digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6 " | "7" | "8" | "9"

The syntax "let x1 x2 ... xN = e1 in e2" is syntactic sugar for "let x1 = \x2 -> ... -> \xN -> e1 in e2" and

the syntax "\x1 x2 ... xN    e" is syntactic sugar for "\x1 -> \x2 -> ... -> xN -> e".

We can use the underscore "_" character to represent a discard binder that can be used in place of a

variable where no binding is required. Pairing of expressions is represented as "(e1,e2)" and there is

no pattern matching in this language so we use "fst" and "snd" to extract the respective components

of a paired expression. For the purposes of this coursework we limit the use of variable names in the

lambda calculus to those drawn from the set "x0 , x1, x2, x3, ... ", that is "x" followed by a natural

number. An example expression in the language is

let x2 x3 _ = x0 in fst ((x2 x4 x5 , x2 x5 x4)) snd ((x2 x4 x5 , x2 x5 x4))

Application binds tightly here and is left associative so "let x = e1 in e2 e3 e4" is to be understood as

"let x = e1 in ((e2 e3) e4)".

Challenge 3: Pretty Printing a Let_x Expression

Consider the datatypes

data LExpr = Var Int | App LExpr LExpr | Let Bind LExpr LExpr | Pair LExpr LExpr | Fst LExpr | Snd LExpr | Abs Bind LExpr

deriving (Eq,Show,Read)

data Bind = Discard | V Int

deriving (Eq,Show,Read)

We use LExpr to represent Abstract Syntax Trees (AST) of the Let_x language.

This challenge requires you to write a function that takes the AST of a Let_x expression and to "pretty

print" it by returning a string representation the expression. That is, define a function

prettyPrint :: LExpr -> String

that outputs a syntactically correct expression of Let_x. Your solution should omit brackets where

these are not required and the output string should parse to the same abstract syntax tree as the

given input. Finally, your solution should print using sugared syntax where possible. For example, an

expression given as Let (V 1) (Abs (V 2) (Abs Discard e1)) e2 should be printed as "let x1 x2 _ = <e1>

in <e2>" where e1 and e2 are expressions and <e1> and <e2> are their pretty print strings.

Beyond that you are free to format and lay out the expression as you choose in order to make it

shorter or easier to read or both.

Example usages of pretty printing (showing the single \ escaped using \\) are:

Challenge 4: Parsing Let_x Expressions

In this Challenge we will write a parser for the Let_x language using the datatype LExpr given above.

Your challenge is to define a function:

parseLetx :: String -> Maybe LExpr

that returns Nothing if the given string does not parse correctly according to the rules of the

concrete grammar for Let_x and returns a valid Abstract Syntax Tree otherwise.

You are recommended to adapt the monadic parser examples published by Hutton and Meijer. You

should start by following the COMP2209 lecture on Parsing, reading the monadic parser tutorial by

Hutton in Chapter 13 of his Haskell textbook, and/or the on-line tutorial below:

http://www.cs.nott.ac.uk/~pszgmh/pearl.pdf on-line tutorial

Example usages of the parsing function are:

App (Abs (V 1) (Var 1)) (Abs (V 1) (Var 1))"(\\x1 -> x1) \\x1 -> x1"

Let Discard (Var 0) (Abs (V 1) (App (Var 1) (Abs (V 1) (Var 1)))) "let _ = x0 in \\x1 -> x1 \\x1 -> x1"

Abs (V 1) (Abs Discard (Abs (V 2) (App (Var 2 ) (Var 1 ) ) ) ) "\\x1 _ x2 -> x2 x1"

App (Var 2) (Abs (V 1) (Abs Discard (Var 1))) "x2 \\x1 _ -> x1"

parseLetx "x1 (x2 x3)" Just (App (Var 1) (App (Var 2) (Var 3)))

parseLetx "x1 x2 x3" Just (App (App (Var 1) (Var 2)) (Var 3))

parseLetx "let x1 x3 = x2 in x1 x2" Just (Let (V 1) (Abs (V 3) (Var 2)) (App (Var 1) (Var 2)))

parseLetx "let x1 _ x3 = x3 in \\x3 ->

x1 x3 x3"

Just (Let (V 1) (Abs Discard (Abs (V 3) (Var 3)))

(Abs (V 3) (App (App (Var 1) (Var 3)) (Var 3))))

Part III  C Encoding Let_x in Lambda Calculus

It is well known that the Lambda Calculus can be used to encode many programming constructs. In

particular, to encode a let blocks we simply use application

<let x0 = e1 in e2> is encoded as (\x0 -> <e2>) <e1> where <e1> and <e2> are the encodings of

e1 and e2 respectively.

To encode the discard binder we simply need to choose a suitable variable with which to replace it:

<\ _ -> e1 > is encoded as (\xN -> <e1>) where xN is chosen so as to not interfere with <e1>

Finally, pairing can be encoded as follows:

< (e1 , e2)> is encoded as (\xN- > xN <e1> <e2> ) where xN does not interfere with <e1> and <e2>

and

<fst e> is encoded as <e> (\x0 - > \x1 - > x0)

<snd e> is encoded as <e> (\x0 - > \x1 - > x1)

Challenge 5: Converting Arithmetic Expressions to Lambda Calculus

Given the datatype

data LamExpr = LamVar Int | LamApp LamExpr LamExpr | LamAbs Int LamExpr

deriving (Eq,Show,Read)

Write a function

letEnc :: LExpr -> LamExpr

that translates an arithmetic expression in to a lambda calculus expression according to the above

translation rules. The lambda expression returned by your function may use any naming of the

bound variables provided the given expression is alpha-equivalent to the intended output.

Usage of the letEnc function on the examples show above is as follows:

letEnc (Let Discard (Abs (V 1) (Var 1)) (Abs (V 1) (Var 1)) LamApp (LamAbs 0 (LamAbs 2

(LamVar 2))) (LamAbs 2 (LamVar

2))

letEnc (Fst (Pair (Abs (V 1) (Var 1)) (Abs Discard (Var 2)))) LamApp (LamAbs 0 (LamApp

(LamApp (LamVar 0) (LamAbs 2

(LamVar 2))) (LamAbs 0 (LamVar

2)))) (LamAbs 0 (LamAbs 1

(LamVar 0)))

Challenge 6: Counting and Comparing Let_x Reductions

For this challenge you will define functions to perform reduction of Let_x expressions. We will

implement both a call-by-value and a call-by-name reduction strategy. A good starting point is to

remind yourself of the definitions of call-by-value and call-by-name evaluation in Lecture 34 -

Evaluation Strategies.

We are going to compare the differences between the lengths of reduction sequences to

terminated for both call-by-value and call-by-name reduction for a given Let_x expression and the

lambda expression obtained by converting the Let_x expression to a lambda expression as defined in

Challenge 5. For the purposes of this coursework, we will consider an expression to have terminated

for a given strategy if it simply has no further reduction steps according to that strategy. For example,

blocked terms such as "x1 x2" are considered as terminated.

In order to understand evaluation in the language of Let_x expressions, we need to identify the

redexes of that language. The relevant reduction rules are as follows:

also note that, in the expressions "let x1 = e1 in e2" or "let _ = e1 in e2" the expression "e2" occurs

underneath a binding operation and therefore, similarly to "\x1 -> e2", according to both call-by-

value and call-by-name strategies, reduction in "e2" is suspended until the binder is resolved.

Define a function:

compareRedn :: LExpr -> Int -> ( Int, Int , Int, Int )

that takes a Let_x expression and upper bound for the number of steps to be counted and returns a

4-tuple containing the length of four reduction sequences. In each case the number returned should

be the minimum of the upper bound and the number of steps needed for the expression to

terminate. Given an input Let_x expression E, the pair should contain lengths of reduction

sequences for (in this order) :

1. termination using call-by-value reduction on E

2. termination using call-by-value reduction on the lambda calculus translation of E

3. termination using call-by-name reduction on E

4. termination using call-by-name reduction on the lambda calculus translation of E

Example usages of the compareRedn function are:

compareRedn (Let (V 3) (Pair (App (Abs (V 1) (App (Var 1) (Var

1))) (Abs (V 2) (Var 2))) (App (Abs (V 1) (App (Var 1) (Var 1))) (Abs

(V 2) (Var 2)))) (Fst (Var 3))) 10

(6,8,4,6)

compareRedn (Let Discard (App (Abs (V 1) (Var 1)) (App (Abs

(V 1) (Var 1)) (Abs (V 1) (Var 1)))) (Snd (Pair (App (Abs (V 1)

(Var 1)) (Abs (V 1) (Var 1))) (Abs (V 1) (Var 1))))) 10

(5,7,2,4)

compareRedn (Let (V 2) (Let (V 1) (Abs (V 0) (App (Var 0) (Var

0))) (App (Var 1) (Var 1))) (Snd (Pair (Var 2) (Abs (V 1) (Var

1))))) 100

(100,100,2,4)

Implementation, Test File and Report

In addition to your solutions to these programming challenges, you are asked to submit an additional

Tests.hs file with your own tests, and a report:

You are expected to test your code carefully before submitting it and we ask that you write a report

on your development strategy. Your report should include an explanation of how you implemented

and tested your solutions. Your report should be up to 1 page (400 words). Note that this report is

not expected to explain how your code works, as this should be evident from your commented code

itself. Instead you should cover the development and testing tools and techniques you used, and

comment on their effectiveness.

Your report should include a second page with a bibliography listing the source(s) for any fragments

of code written by other people that you have adapted or included directly in your submission.

Submission and Marking

Your Haskell solutions should be submitted as a single plain text file Challenges.hs. Your tests should

also be submitted as a plain text file Tests.hs. Finally, your report should be submitted as a PDF file,

Report.pdf.

The marking scheme is given in the appendix below. There are up to 5 marks for your solution to

each of the programming challenges, up to 5 for your explanation of how you implemented and

tested these, and up to 5 for your coding style. This gives a maximum of 40 marks for this

assignment, which is worth 40% of the module.

Your solutions to these challenges will be subject to automated testing so it is important that you

adhere to the type definitions and type signatures given in the supplied dummy code file

Challenges.hs. Do not change the list of functions and types exported by this file. Your code will be

run using a command line such as ghc  Ce   main   CW2TestSuite.hs, where CW2TestSuite.hs is my test

harness that imports Challenge.hs. You should check before you submit that your solution compiles

and runs as expected.

The supplied Parsing.hs file will be present so it is safe to import this and any library included in the

standard Haskell distribution (Version 8.10.7). Third party libraries will not be present so do not

import these. We will not compile and execute your Tests.hs file when marking.

Appendix: Marking Scheme

Guidance on Coding Style and Readability

Grade Functional Correctness Readability and Coding Style Development & Testing

請加QQ：99515681 或郵箱：99515681@qq.com   WX：codehelp