QuasiQuotation

Due Monday Sept. 23rd @ 9 am

From this assignment, students will show...

Abstractions and Representations - Recognition

...by recognizing what patterns of writing TH and Parser programs (as an intended user) fit with the solution QuasiQuotation provides.

Technical Reading Comprehension - Recognition

...by recognizing the similarities and differences presented by the TH paper with the problem solution provided here.

Technical Writing - Recall

...by providing complete sentences and illustrating their intent during the writing activities (e.g. providing a claim, an example or analogy, and an effect or impact).

Language FrontEnd Design - Recognition

...by recognizing the language design decisions we have talked about (and saw in real PL reviews) as they motivate this tool which provides a way to extend Haskell with custom concrete syntax.

CodeGen and Metaprogramming - Recognition

...by recognizing the problems we've discussed that language implementers have and how they are solved with this solution.

Documentation and Usability - Recognition

...by considering the perspectives of the users of the tool (program designers) and the perspectives of the users of what the language designers produce (quasiquoter front ends) and what usability tradeoffs exist.

Composing Feedback and Evaluation - Recognition

...by providing postive, constructive (actionable) feedback or advice to language designers looking to use QuasiQuoters as a solution.

Let's begin

The QuasiQuotation paper can be found here in addition to the reading repo.

We believe this is the second most technically difficult paper in this course (with the TH paper being the most difficult). Matthew decided to schedule this paper after the TH paper since we would be doing TH examples before writing our own Parsers and quasiquoters. Conceptually, however, there is a lot of overlap with the TH paper and the same ideas about compile time Haskell code generation are present in this paper.

Much like TemplateHaskell, Quasiquotation has changed a lot since the paper. Please let haskell wiki reference fill in any gaps and be the defacto standard for our implementations going forward.

Please answer the following questions

Decision Process: Should I..?

A programmer friend says they have been writing a lot of programs to automate common social media tasks. E.g. automatic editing and posting from a source blog, timed reminders, keyword search, etc. The have desgined an Algebraic Data Type to represent all the information from various social media sources they care about. They ask you whether they should write a DSL for abstracting these tasks.

A sample of what their programs might look like are here in the Exemplar's repo. Note, this code will not run because many of the calls are not instantiated. This pseudocode exists to give you an idea what what they have to do by hand, what they might be using IO and State for, etc. Also, having these concrete examples will give you practice reading type signatures and do-notation, so please ask questions if you would like clarifiaction or help interpretting these examples in any way.

Fill out the {blanks} in the following structure such that your friend can decide for themselves whether or not they should make a language. You can write the questions as specific or generic to the domain of social media tasks as you like, but you cannot make the decision for your friend. E.g. you cannot tell them what to choose, only how to choose. If you find the template below inadequate for representing your advice or decision process, feel free to modify or provide your own, this is just a suggested format.

  1. Should you make a library of plain-ol' Haskell functions?
  2. Should you make a library of Template Haskell programs (metaprograms, compile time functions)?
  3. Should you make a quasiquoter with a parser for a custom concrete syntax?
If you get stuck, asking yourself the following questions might help: What are they doing at runtime that would be good to do at compile time? What code are they repeating? What looks awkward in the Haskell Syntax? What are they having to do extra steps for by using the StateT and IO monads? What could they assume should always be true?

Optional META.md

META.md should include
  1. your name
  2. your utln
  3. how much time you spent on this assignment
  4. the witness "proof" for how you earned each learning objective with a note about recall for recall objectives

Please Submit

Contents to be submitted

Method of submission

Please commit your changes in the hw07-1 directory of your private repo and push them to the remote server before 9 am.