My reference.
Another reference.
tags. You do not need to consider how to
handle newlines.
, while each line within the
blockquote must be encased with a tag.
This is a block quote.
It can span multiple lines.
Code (0.5 marks)
The code block must be encased in both the and the tags. If there is a
language identifier (e.g., haskell), it must be included within the class attribute,
prefixed by language-. Otherwise, there should not be any class attribute. The
newlines and code indentation must remain.
main :: IO ()
main = do
putStrLn "Never gonna give you up"
putStrLn "Never gonna let you down"
putStrLn "Never gonna run around and desert you"
Never gonna let you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Ordered Lists (1 marks)
Ordered lists must begin and end with the tag, and each list item must begin and
end with the opening/closing - tag.
- Item 1
- Sub Item 1
- Sub Item 2
- Sub Item 3
- Bolded Item 2
- Item 3
- Item 4
Tables (1 mark)
The HTML convention for representing tables involves using the , ,
, and | elements. represents the entire table, represents a
row within the table, represents a header cell within a table row, used for the
header row, and | represents a data cell within a table row, used for the content
rows.
You may optionally include and | tags. Either of these outupts is
acceptable:
Tables |
Are |
Cool |
|---|
here |
is |
data |
here |
is |
data |
here |
is also |
bolded data |
also |
part of the |
table |
Tables |
Are |
Cool |
|---|
here |
is |
data |
here |
is |
data |
here |
is also |
bolded data |
also |
part of the |
table |
Part C (6 marks): Adding extra functionality to the webpage
This task involves changing the webpage to include extra capabilities allowing a more
feature-full UI. You will not be marked on the layout, or ease of use of features, as long
as they are clearly visible to your marker, e.g., a button should be clearly visible on the
screen. This task will involve some light additions to both the HTML page and
TypeScript code. This will likely involve creating an observable stream for the data,
merging it into the subscription stream, and sending the information to the Haskell
backend. The communicated information between the Haskell backend and the
webpage will need to be updated to include additional information that the user wants
the engine to achieve.
● A button must be added to the webpage for saving, where the converted HTML
is saved using Haskell. The user does not need to be prompted for a file name,
and the HTML should be saved according to the current time, formatted in ISO
8601 format for the current date and time: YYYY-MM-DDTHH:MM:SS. The
function getTime is provided which will provide you this time in an IO String
format.
● A separate input box, to allow the user to change the title of the page, instead of
the default Converted HTML.Part D (up to 6 bonus marks): Extension
Implement anything that is interesting, impressive, or otherwise “shows off” your
understanding of Haskell, Functional Programming, and/or Parsing.
To achieve the maximum amount of bonus marks, the feature should be similar in
complexity to Part C (6 marks):
The bonus marks only apply to this assignment, and the final mark for this assignment
is capped at 30 marks (100%). This means you cannot score more than 30 marks or
100%.
Some suggestions for extensions of varying complexity and difficulty:
● Markdown validation
○ E.g., enforce all table columns have the same width
● Correct BNF for the Markdown you are parsing in report (worth 2 marks)
○ For any part of the parser which is not context-free, you may simplify the
parsing rules to be context-free.
● Further extensions to the webpage for extra features, using RxJS
● Parse nested text modifiers, such as **_bold and italics_** and [click
**here**](https://example.com)
● Parse further parts of the markdown specification which make use of interesting
parsers, which you have not used in other parts of the assignment.
● Comprehensive test cases over the parser and pretty printing
○ Warning: It is super hard to be comprehensive, stay away unless you love
testing.
(Choosing one of the simpler suggestions to implement may not receive the maximum
available marks).Report (2 marks)
You are required to provide a report in PDF format of max. 600 words (markers will not
mark beyond this word limit). Descriptions of extensions can use up to 200 words per
extension feature.
Make sure to summarise the intention of the code, and highlight the interesting parts
and difficulties you encountered. Focus on the "why" not the "how".
Additionally, just posting screenshots of code is heavily discouraged, unless it
contains something of particular importance. Remember, markers will be looking at your
code alongside your report, so we do not need to see your code twice.
Importantly, this report must include a description of why and how parser combinators
helped you complete the parsing. In summary, your report should include the following
sections:
● Design of the code (including data structures)
○ High-level description of approach
○ High-level structure of code
○ Code architecture choices
● Parsing
○ Usage of parser combinators
○ Choices made in creating parsers and parser combinators
○ How parsers and parser combinators were constructed using the Functor,
Applicative, and Monad typeclasses
● Functional Programming (focusing on the why)
○ Small modular functions
○ Composing small functions together
○ Declarative style (including point free style)
● Haskell Language Features Used (focusing on the why)
○ Typeclasses and Custom Types
○ Higher order functions, fmap, apply, bind
○ Function composition
● Description of Extensions (if applicable)
○ What you intended to implement
○ What you did implement
○ What is cool/interesting/complex about it
○ This may include using Haskell features that are not covered in course
content
There is some overlap between the sections. You should avoid repeating descriptions
or ideas in the report.Code Quality (4 marks)
Code quality will relate more to how understandable your code is. You must have
readable and functional code, commented when necessary. Readable code means
that you keep your lines at a reasonable length (< 80 characters), that you provide
comments above non-trivial functions, and that you comment sections of your code
whose function may not be clear.
Your functions should all be small and modular, building up in complexity, and taking
advantage of built-in functions or self-defined utility functions when possible. It should
be easy to read and understand what each piece of your code is doing, and why it is
useful. Do not reimplement library functions, such as map, and use the appropriate
library function when possible.
Your code should aim to re-use previous functions as much as possible, and not repeat
work when possible.
Code quality includes your ADT and if it is well structured, i.e., does not have a bunch of
repeated data types and follows a logical manner (the JSON example from the applied
session is a good example of what an ADT should look like).Marking breakdown
The main marking criteria for each parsing and pretty printing exercise consists of two
parts: correctness and FP style. Both correctness and FP style will be worth 50% of
the marks for each of the exercises, i.e., if your code passes all tests, you will get at
least half marks for Exercise A, and Exercise B.
You will be provided with some sample input and tests for determining the validity of the
outputted HTML files. The sample inputs provided will not be exhaustive, you are
heavily encouraged to add your own, perhaps covering edge cases.
Correctness
We will be running a series of tests which test each exercise, and depending on how
many of the tests you pass, a proportion of marks will be awarded
FP Style
FP style relates to if the code is done in a way that aligns with the unit content and
functional programming.
You must apply concepts from the course. The important thing here is that you need to
use what we have taught you effectively. For example, defining a new type and its
Monad instance, but then never actually needing to use it will not give you marks. Note:
using bind (>>=) for the sake of using the Monad when it is not needed will not count
as "effective usage."
Most importantly, code that does not utilise Haskell's language features, and that
attempts to code in a more imperative style, will not be awarded high marks.
Minimum Requirements:
An estimate of a passing grade will be parsing up to and including code blocks, but not
lists or tables, where the difficulty and the marks step up. However, this will need to be
accompanied by high code quality and a good report.
A higher mark will require parsing of the more difficult data structures, and modifications
of the HTML page.Changelog
● Add note that text modifiers must be non-empty
● Add note about BNF can simplify parser, if and only if the parser is not context
free.
● 18 Sep: Remove the requirement to parse nested text modifiers and instead
make that an extension
● 18 Sep: Fix issue in scaffold where frontend would show output HTML with a
leading and trailing quote
● 20 Sep: Changed “Abstract Data Type” to “Algebraic Data Type” (under Part A)
● 24 Sep: Clarify that URLs in images should not consider text modifiers
● 25 Sep: Clarify that there should be no spaces after ! and before [ in images
● 25 Sep: Clarify whitespace rules for images, footnote references, headings,
blockquotes, code blocks, and tables
● 25 Sep: Specify how to convert a code block with no language identifier to HTML
● 28 Sep: Allow optionally including and when rendering tables
● 29 Sep: Fix indentation in ordered list HTML output
- QQ：99515681
- 邮箱：99515681@qq.com
- 工作时间：8:00-23:00
- 微信：codinghelp
|