Case Study: DeckBuild

From doing these activities students will

Motivation

This case study was made by Karl, Matt, and Raoul (Alumnus) for the 2014f PLD class. By dissecting it, answering some questions, and then editing it, we have two goals. One is to reinforce your current understanding of the Language Design pipeline. The other is to provide you with a concrete example for how you could organize your DSL as a stack haskell project.

You are not expected to be DeckBuild masters in 1.25 hours, but we hope you can glom onto familiar pieces of code and, from there, ask questions.

Warm-up activity - 10 min (9:00 ~ 9:10)

Here are the rules for the game, Dominion, which DeckBuild was based on. Using these slides (specifically slide 4) as a reference, write a DeckBuild program for the following Dominion card:

Oasis - Action

Small group discussion - 30 min (9:10 ~ 9:40)

At a high level, implement the discard a card as a primtive expression rather than a string description.

AST

The AST acts as a intermediate representation and contract between the parser and the generator, so it is a good place to start. Consider the data declarations between line 100 and line 125 Syntax.hs. Where and how would you add an AST representation for the Discard effect?

Parser

How would you extend Parser.hs to support this new primitive?

CodeGen

The codegen for DeckBuild can remain the same, most likely. What the codegen primarily does is generate runtime representations of the cards as datatype instances.

Question: The function genCardCons makes a right hand side for the datatype RuntimeCard, but does not depend on user program input. (look, it takes no arguments, what gives?). Matt and Karl assert that, due to their abstraction and representation choices, this data type declaration must be generated, and not written statically in a library. Why do you think that is?

To help you answer this question, consider this generated output from the flag --ddump-splices for the code in /test/BaseQuote.hs

Runtime

The runtime was located in a separate project. The runtime library is primarily described in Lib.hs. Look for the other parts of the AST datatype you edited to find where to augment the runtime, and look at the functions addMoney and friends to see how pother effects are handled at runtime. What would you add to finish implementing the functionality?

Asking the user for input does not yet have a combinator in this runtime library, so imagine you could make any function. E.g. suppose we could implement a function: pick :: (Monad m, MonadState Game m) => m CardName

Optional Meta lesson: Matt wrote a runtime component to act as a webserver around this core runtime library. Karl wrote a probablistic programming project (for Norman's PPL class) around this core library. We had success in building several small pieces of functionality and composing them together, but then had a harder time having a cohesive evaluation (and we had too much fun in software engineering land. This struggle motivated Matt's decision to have everyone this year build a stand alone language themselves from end to end).

Large group discussion - 30min (9:40 ~ 10:10)

Live code new feature.

Cool-down activity - 05 min (10:10 ~ 10:15)

All scribes will get together to start their wiki write up to be finished at latest a week from today.

All managers will make tickets for the course. This can include the tickets from their group discussions as mentioned above, a ticket to follow up on the scribe write up, and any other issues they think will be helpful.

Managers may get together with Matthew and Kathleen to discuss how they think the day went, how they think the pacing went, what they are looking forward to, any worries they might have about the class, etc.

Class Dismissed