info/teamwork.md

+To monitor fair division of work in your groups, we ask that each of you sends us an _individual_ email, from your EPFL address, to both PhD assistants and the instructor via **email**.
+The email should contain an estimate how much you and your team mates contributed to each of the four common projects and to the self-chosen final project, with * next to your name, in the form of a table with percentages rounded down, e.g., with a perfect split:
+
+Person1 Lab1:33%, Lab2:33%, Lab3:33%, Lab4:33%, Lab5: 33%, Project: 33%
+Person2* Lab1:33%, Lab2:33%, Lab3:33%, Lab4:33%, Lab5: 33%, Project: 33%
+Person3 Lab1:33%, Lab2:33%, Lab3:33%, Lab4:33%, Lab5: 33%, Project: 33%
+
+Every column should add to 99 or 100; if you each repeated the same work (e.g. each of you solved Lab1 entirely on your own but only one solution was taken), please renormalize and devide "redundantly" done work evenly.
+
+After that, please add any specific clarifications and explanations _if_ you feel it is helpful, but try to keep them no longer than 10 sentences.
+
+We leave it to each of you whether you discuss and reconcile these numbers and claims within the group. In any case, we would like to receive emails from _individual_ students, without CC or BCC to the remaining group members. Hence, in some cases we may see contradictory information if that reflects how people feel. The email title should be "My Teamwork Statement CS-320". If you have any issues or questions regarding this, please ask here on Ed, or directly to the same emails (but a clarification email should have a somewhat different title, like "Question on Teamwork Statement").
+
+If we get nearly 33% for everything from every group member of a 3-person group (with or without explanations), we will trust this group did a fair split and leave it at that. Else, we may follow up with you in the following weeks. We will try to use this information in a positive way, and we hope that this final step will not ruin any otherwise working group dynamics.
+
+We ask you to submit teamwork statements twice:
+  * on the day after the deadline for Lab 3
+  * on the day after the deadline for the final lab (extension project)
+  

labs/amy_reference_compiler.md

-# The Amy Reference Compiler
-
-We provide you with a reference compiler for the Amy language that you can use to explore the expected behavior of your own compiler.
-
-The reference compiler is [available here](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/amyc-assembly-1.7.jar).
-
-You can run it as follows:
-  java -cp amyc-assembly-1.7.jar amyc.Main [options] [input files]
-
-To see the list of available options do 
-  java -cp amyc-assembly-1.7.jar amyc.Main --help
-
-The easiest way to execute a program is to run it in `--interpret` mode. If you want to generate WebAssembly binary code, you should follow these steps:
-  * Install `nodejs`. We have tested amyc with Node version 12, though other versions might work. See the [Node website](https://nodejs.org/en/) for installation instructions.
-  * Make sure the `wat2wasm` executable is visible, i.e., it is in the system path or, for Linux or Mac, you are at the toplevel of the `amyc` directory.
-  * Run `npm install deasync` in the directory you plan to run `amyc`.
-  * Run `amyc` without options. You will get a few output files.
-  * Run `nodejs <output file>.js`
-
-
-# Bug Reports
-
-We welcome bug reports! Please use the forum on Moodle for this purpose.

labs/amy_specification.md

-# The Amy Specification 
-
-You can access the Amy specification document [here](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/amy_specification.pdf).

labs/labs06_material/presentation.md

-## Compiler Extension Presentation Instructions
-
-Background presentations will take place in week 14. 
-
-**The presentation should be 10 minutes long.**
-
-**Q&A session of 5-10 minutes** will follow right after the
-presentation. 
-
-Shortly after, you will receive feedback from us regarding the content
-of your presentation, as well as some general feedback on the form.
-
-### Presentation content
-
-Your presentation should summarize your project. In particular, we\'d
-expect to see
-
--   a basic overview of the features you added to the compiler/language
--   some (short) programs highlighting the use of these features, with a
-    description of how your extended compiler behaves on them
--   possibly some theoretical background you had to learn about to
-    implement the extension
--   an overview of the changes you made to each compiler phase and/or
-    which phases you added
-
-### Presentation style
-
-Here are some useful resources on how to prepare and give talks:
-
--   [How To Speak by Patrick
-    Winston](https://www.youtube.com/watch?v=Unzc731iCUY)
--   [How to give a great research talk by Simon Peyton
-    Jones](https://www.microsoft.com/en-us/research/academic-program/give-great-research-talk/)
-
-Please do not use Viktor\'s videos as a model for the presentation, but
-instead incorporate as many points of the talk of [Patrick
-Winston](https://en.wikipedia.org/wiki/Patrick_Winston) as you believe
-apply to your presentation. It is an amazing and entertaining talk,
-despite (or because) it is meta-circular: he does as he says. Note:
-breaking physical objects or referring to supernatural beings in your
-video is not required. Use your own judgment and strike a balance in
-being comfortable with what and how you are saying things and trying out
-these pieces of advice.

labs/labs_01.md

-Below you will find the instructions for the first lab assignment in which you will get to know and implement an interpreter for the Amy language. If you haven't looked at the [Labs Setup](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/labs_setup.md) page yet, please do so before starting out with the assignment.
-
-
-# Part 1: Your first Amy programs
-
-Write two example Amy programs each and make sure you can compile them using the [Amy Reference Compiler](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/amy_reference_compiler.md). Put them under `/examples`. Please be creative when writing your programs: they should be nontrivial and not reproduce the functionality of the examples in the `/library` and `/examples` directories of the repository. Of course you are welcome to browse these directories for inspiration.
-
-Remember that you will use these programs in the remaining of the semester to test your compiler, so don't make them too trivial! Try to test many features of the language.
-
-If you have questions about how a feature of Amy works, you can always look at the [Amy Specification](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/amy_specification.md). It's a good idea to keep a local copy of this document handy -- it will be your reference for whenever you are asked to implement an aspect of the Amy language throughout this semester.
-
-
-# Part 2: An Interpreter for Amy ([Slides](slides/lab01.pdf))
-
-The main task of the first lab is to write an interpreter for Amy. 
-
-(If you haven't been assigned your repository yet, you can download a packaged version of the interpreter lab's skeleton [here](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/labs01_material/clp-lab01.zip). If you already have your repository assigned, you can simply check out the `lab01` branch. Note that future labs will only be distributed through the repository, so be sure to familiarize yourself with the setup.)
-
-
-## Interpreters 
-
-The way to execute programs you have mostly seen so far is compilation to some kind of low-level code (bytecode for a virtual machine such as Java's; native binary code in case of languages such as C). An alternative way to execute programs is interpretation. According to Wikipedia, "an interpreter is a computer program that directly executes, i.e. performs, instructions written in a programming or scripting language, without previously compiling them into a machine language program". In other words, your interpreter is supposed to directly look at the code and *interpret* its meaning. For example, when encountering a call to the 'printString' function, your interpreter should print its argument on the standard output.
-
-## The general structure of the Interpreter 
-
-The skeleton of the assignment is provided by us in three files:
-
-- The `Main.scala` source file
-
-- The `Interpreter.scala` source file, and
-
-- the `amyc-frontend-1.7.jar` bytecode file, which is located under `lib/` .
-
-Now let's look into the code in a little more detail.
-
-In `Main.scala`, take a look at the main method, which is the entry point to your program. After processing the command line arguments of the interpreter, the main method creates a Pipeline, which contains the different stages of the compiler (more on it in later assignments). The Pipeline will first call the Amy frontend, which will parse the source program into an abstract syntax tree (AST) and check it for correctness according to the [Amy specification](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/amy_specification.md), and then passes the result to the Interpreter.
-The implementation of the frontend is given to you in compiled form, because you will need to write your own version in the next assignments. **Note**: You are only allowed to use this binary code to link against your interpreter.
-
-So what is this AST we've mentioned? For the computer to "understand" the meaning of a program, it first has to transform it from source (text) form to a more convenient form, which we call an abstract syntax tree. The AST abstracts away uninteresting things of the program (e.g. parentheses, whitespace, operator precedence...) and keeps the essential structure of the program. 
-
-In Scala, we represent the AST as a tree-form object. The tree has different types of nodes, each one representing a different programming structure. The types of nodes are of course represented as different classes, which all inherit from a class called Tree. Conveniently enough, the classes correspond pretty much one-to-one to the rules of the BNF grammar given in the language specification. E.g. in the language spec we read that a module looks as follows:
-
-Module ::= **object** Id Definition* Expr? **end** Id
-
-and indeed in the implementation we find a class 
-
-`case class ModuleDef(name: Identifier, defs: List[ClassOrFunDef], optExpr: Option[Expr]) extends Definition`
-
-You can find the source code of the AST [here](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/labs01_material/SymbolicTreeModule.scala).
-Note: This is not exactly the code we will use in later assignments, but it's good enough to serve as a reference while implementing this first assignment.
-
-
-## The Interpreter class
-
-Now let's delve into `Interpreter.scala`. This file currently only contains a partial implementation, and it is your task to complete it! The entrypoint into the interpreter is `interpret`, which takes an expression as input and executes its meaning. The main loop at the end of the class will just take the modules in order and interpret their expression, if present.
-
-`interpret` returns a `Value`, which is a type that represents a value that an Amy expression can produce. Value is inherited by classes which represent the different types of values present in Amy (`Int(32)`, `Booleans`, `Unit`, `String` and ADT values). `Value` has convenience methods to cast to `Int(32)`, `Boolean` and `String` (`as*`). Remember we can always call these methods safely when we know the types of an expression (e.g. the operands of an addition), since we know that the program type-checks.
-
-`interpret` takes an additional implicit parameter as an argument, which is a mapping from variables to values (in the interpreted language). In Scala, when an implicit parameter is expected, the compiler will look in the scope for some binding of the correct type and pass it automatically. This way we do not have to pass the same mapping over and over to all recursive calls to `interpret`. Be aware, however, that there are some cases when you need to change the `locals` parameter! Think carefully about when you have to do so.
-
-A few final notes:
-
-  * You can print program output straight to the console.
-  * You can assume the input programs are correct. This is guaranteed by the Amy frontend. 
-  * To find constructors and functions in the program, you have to search in the `SymbolTable` passed along with the program. To do this, use the three helper methods provided in the interpreter:
-    * `isConstrutor` will return whether the `Identifier` argument is a type constructor in the program
-    * `findFunctionOwner` will return the module which contains the given `Identifier`, which has to be a function in the program. E.g. if you give it the `printInt` function of the `Std` module, you will get the string `"Std"`.
-    * `findFunction` will return the function definition given a pair of Strings representing the module containing the function, and the function name. The return value is of type `FunDef` (see [the AST definitions](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/labs01_material/SymbolicTreeModule.scala)).
-  * When comparing Strings by reference, compare the two `StringValue`s directly and not the underlying Strings. The reason is that the JVM may return true when comparing Strings by equality when it is not expected (it has to do with JVM constant pools).
-  * Some functions contained in the `Std` module are built-in in the language, i.e. they are hard-coded in the interpreter because they cannot be implemented in Amy otherwise. An example of a built-in function is `printString`. When you implement the interpreter for function calls, you should first check if the function is built-in, and if so, use the implementation provided in the `builtIns` map in the interpreter.
-  * When a program fails (e.g. due to a call to `error` or a match fail), you should call the dedicated method in the Context: `ctx.reporter.fatal`.
-
-## Implementation skeleton 
-
-If you have followed [Labs Setup](https://gitlab.epfl.ch/lara/cs320/-/blob/main/labs/labs_setup.md) for Lab 01, you should have a working project with a stub implementation, containing the following files:
-
-  * `src/amyc/interpreter/Interpreter.scala` contains a partially implemented interpreter
-  * `src/amyc/Main.scala` contains the `main` method which runs the interpreter on the input files
-  * The `library` directory contains library definitions you can call from your programs.
-  * The `examples` directory contains some example programs on which you can try your implementation. Remember that most of them also use library files from `/library`.
-  * `lib/amy-frontend-1.7.jar` contains the frontend of the compiler as a library, allowing you directly work with type-checked ASTs of input programs.
-
-You will have to complete the interpreter by implementing the missing methods (marked with the placeholder `???`).
-
-
-## Testing
-
-When you are done, use sbt to try some of your programs from Part 1:
-
-```
-  $ sbt
-  > run library/Std.scala examples/Hello.scala
-  Hello world!
-```
-
-There is also testing infrastructure under `/test`. To add your own tests, you have to add your testcases under `/test/resources/interpreter/passing`
-and the expected output under 
-`/test/resources/interpreter/outputs`.
-Then, you have to add the name of the new test in `InterpreterTests`, similarly to the examples given.
-To allow a test to also use the standard library (e.g., `Std.printString`), you can copy `Std.scala` from `library/Std.scala` to `/test/resources/interpreter/passing`.
-
-For example, to add a test that expects only "Hello world" to be printed, you can add "/test/resources/interpreter/passing/Hello.scala" containing `object Hello Std.printString("Hello world") end Hello` and `/test/resources/interpreter/outputs/Hello.txt` containing `Hello world` (with a newline in the end!). You will also have to add a line to `/test/scala/amyc/test/InterpreterTests.scala`:  `@Test def testHello = shouldOutput(List("Std", "Hello"), "Hello")`. This will pass both files `Std.scala` and `Hello.scala` as inputs of the test. When you now run `test` from sbt, you should see the additional test case (called `testHello`).
-
-
-## Deliverables
-You are given **2 weeks** for this assignment.
-
-Deadline: **Friday October 8 at 11 pm**.
-
-Submission: one team member submits a zip file submission-groupNumber.zip to the [moodle submission page](https://moodle.epfl.ch/mod/assign/view.php?id=1169243).
-
-
-## Related documentation 
-
-  * End of Chapter 1 in the Tiger Book presents a similar problem for another mini-language. A comparison of the implementation of ASTs in Java (as shown in the book) and Scala is instructive.

labs/labs_04.md

-# Lab 04: Type Checker ([Slides](slides/lab04.pdf))
-
-Parsing concludes the syntactical analysis of Amy programs. Having
-successfully constructed an abstract syntax tree for an input program,
-compilers typically run one or multiple phases containing checks of a
-more semantical nature. Virtually all high-level programming languages
-enjoy some form of name analysis, whose purpose is to disambiguate
-symbol references throughout the program. Some languages go further and
-perform a series of additional checks whose goal is to rule out runtime
-errors statically (i.e., during compilation, or in other words, without
-executing the program). While the exact rules for those checks vary from
-language to language, this part of compilation is typically summarized
-as \"type checking\". Amy, being a statically-typed language, requires
-both name and type analysis.
-
-## Prelude: From Nominal to Symbolic Trees
-
-Recall that during parsing we created (abstract syntax) trees of the
-*nominal* sort: Names of variables, functions and data types were simply
-stored as strings. However, two names used in the program could be the
-same, but not refer to one and the same \"thing\" at runtime. During
-name analysis we translate from nominal trees to symbolic ones, to make
-it clear whether two names refer to one and the same underlying entity.
-That is, we explicitly replace strings by fresh identifiers which will
-prevent us from mixing up definitions of the same name, or referring to
-things that have not been defined. Amy\'s name analyzer is provided to
-you as part of this lab\'s skeleton, but you should read the [dedicated
-name analyzer page](labs04_material/NameAnalysis.md) to understand how it works.
-
-## Introduction to Type Checking
-
-The purpose of this lab is to implement a type checker for Amy. Our type
-checking rules will prevent certain errors based on the kind or shape of
-values that the program is manipulating. For instance, we should prevent
-an integer from being added to a boolean value.
-
-Type checking is the last stage of the compiler frontend. Every program
-that reaches the end of this stage without an error is correct (as far
-as the compiler is concerned), and every program that does not is wrong.
-After type checking we are finally ready to interpret the program or
-compile it to binary code!
-
-Typing rules for Amy are presented in detail in the
-[Amy specification](amy_specification.md). Make sure to check correct
-typing for all expressions and patterns.
-
-## Implementation
-
-The current assignment focuses on the file `TypeChecker.scala`. As
-usual, the skeleton and helper methods are given to you, and you will
-have to complete the missing parts. In particular, you will write a
-compiler phase that checks whether the expressions in a given program
-are well-typed and report errors otherwise.
-
-To this end you will implement a simplified form of the Hindley-Milner
-(HM) type-inference algorithm that you\'ll hear about during the
-lectures. Note that while not advertised as a feature to users of Amy,
-behind the scenes we will perform type inference. It is usually
-straightforward to adapt an algorithm for type inference to type
-checking, since one can add the user-provided type annotations to the
-set of constraints. This is what you will do with HM in this lab.
-
-Compared to the presentation of HM type inference in class your type
-checker can be simplified in another way: Since Amy does not feature
-higher-order functions or polymorphic data types, types in Amy are
-always *simple* in the sense that they are not composed of arbitrary
-other types. That is, a type is either a base type (one of `Int`, `Bool`
-and `String`) or it is an ADT, which has a proper name (e.g. `List` or
-`Option` from the standard library). In the latter case, all the types
-in the constructor of the ADT are immediately known. For instance, the
-standard library\'s `List` is really a list of integers, so we know that
-the `Cons` constructor takes an `Int` and another `List`.
-
-As a result, your algorithm will never have to deal with complex
-constraints over type constructors (such as the function arrow
-`A => B`). Instead, your constraints will always be of the form
-`T1 = T2` where `T1` and `T2` are either *simple* types or type
-variables. This is most important during unification, which otherwise
-would have to deal with complex types separately.
-
-Your task now is to a) complete the `genConstraints` method which will
-traverse a given expression and collect all the necessary typing
-constraints, and b) implement the *unification* algorithm as
-`solveConstraints`.
-
-Familiarize yourself with the `Constraint` and `TypeVariable` data
-structures in `TypeChecker.scala` and then start by implementing
-`genConstraints`. The structure of this method will in many cases be
-analogous to the AST traversal you wrote for the name analyzer. Note
-that `genConstraints` also takes an *expected type*. For instance, in
-case of addition the expected type of both operands should be `Int`. For
-other constructs, such as pattern `match`es it is not inherently clear
-what should be the type of each `case` body. In this case you can create
-and pass a fresh type variable.
-
-Once you have a working implementation of both `genConstraints` and
-`solveConstraints` you can copy over your previous work on the
-interpreter and run the programs produced by your frontend! Don\'t
-forget that to debug your compiler\'s behavior you can also use the
-reference compiler with the `--interpret` flag and then compare the
-output.
-
-## Skeleton
-
-As usual, you can find the skeleton for this lab in a new branch of your
-group\'s repository. After merging it with your existing work, the
-structure of your project `src` directory should be as follows:
-
-    src/amyc
-     ├── Main.scala                (updated)
-     │
-     ├── analyzer                  (new)
-     │    ├── SymbolTable.scala
-     │    ├── NameAnalyzer.scala
-     │    └── TypeChecker.scala
-     │
-     ├── ast
-     │    ├── Identifier.scala
-     │    ├── Printer.scala
-     │    └── TreeModule.scala
-     │
-     ├── interpreter
-     │    └── Interpreter.scala
-     │
-     ├── lib
-     │    ├── scallion_3.0.6.jar
-     │    └── silex_3.0.6.jar
-     │
-     ├── parsing
-     │    ├── Parser.scala
-     │    ├── Lexer.scala
-     │    └── Tokens.scala
-     │
-     └── utils
-          ├── AmycFatalError.scala
-          ├── Context.scala
-          ├── Document.scala
-          ├── Pipeline.scala
-          ├── Position.scala
-          ├── Reporter.scala
-          └── UniqueCounter.scala
-
-## Deliverables
-
-You are given **1 week** for this assignment.
-
-Deadline: **Wednesday November 17 at 11 pm**.
-
-Submission: one team member submits a zip file submission-groupNumber.zip to the [moodle submission page]().
-
-Your submission only needs to contain your `src` directory. 
-You can use the following command (from the root of your repository) to generate the archive:
-```
-zip -r submission-<groupNumber>.zip src/
-```
-
-You can then verify the content of the archive using `unzip -l submission-<groupNumber>.zip`

labs/labs_05.md

-# Lab 05: Code Generation(Slides: [Markdown](slides/lab05.md)/[HTML](slides/lab05.html))
-
-## Introduction
-
-Welcome to the last common assignment for the Amy compiler. At this
-point, we are finally done with the frontend: we have translated source
-programs to ASTs and have checked that all correctness conditions hold
-for our program. We are ready to generate code for our program. In our
-case the target language will be *WebAssembly*.
-
-WebAssembly is \"a new portable, size- and load-time-efficient format
-suitable for compilation to the web\" (<http://webassembly.org>).
-WebAssembly is designed to be called from JavaScript in browsers and
-lends itself to highly-performant execution.
-
-For simplicity, we will not use a browser, but execute the resulting
-WebAssembly bytecode directly using `nodejs` which is essentially a
-standalone distribution of the Chrome browser\'s JavaScript engine. When
-you run your complete compiler (or the reference compiler) with no
-options on program `p`, it will generate four different files under the
-`wasmout` directory:
-
--   `p.wat` is the wasm output of the compiler in text format. You can
-    use this representation to debug your generated code.
--   `p.wasm` is the binary output of the compiler. This is what `nodejs`
-    will use. To translate to the binary format, we use the `wat2wasm`
-    tool provided by the WebAssembly developers. For your convenience we
-    have included it in the `bin` directory of the skeleton. Note that
-    this tool performs a purely mechanical translation and thus its
-    output (for instance, `p.wasm`) corresponds to a binary
-    representation of `p.wat`.
--   `p.js` is a JavaScript wrapper which we will run with nodejs and
-    serve as an entrypoint into your generated binary.
-
-To run the program, simply type `nodejs wasmout/p.js`
-
-### Installing nodejs
-
--   You can find directions for your favorite operating system
-    [here](https://nodejs.org/en/). You should have nodejs 12 or later
-    (run `nodejs --version` to make sure).
--   Once you have installed nodejs, run `npm install deasync` from the
-    directory you plan to run `amyc` in, i.e. the toplevel directory of
-    the compiler.
--   Make sure the `wat2wasm` executable is visible, i.e. it is in the
-    system path or you are at the toplevel of the `amyc` directory.
-
-## WebAssembly and Amy
-
-The slides for this year's presentation are in the files called lab05-slides.
-
-Look at [this
-presentation](http://lara.epfl.ch/~gschmid/clp20/codegen.pdf) for the
-main concepts of how to translate Amy programs to WebAssembly.
-
-You can find the annotated compiler output to the concat example
-[here](http://lara.epfl.ch/~gschmid/clp20/concat.wat).
-
-## The assignment code
-
-### Overview
-
-The code for the assignment is divided into two directories: `wasm` for
-the modeling of the WebAssembly framework, and `codegen` for
-Amy-specific code generation. There is a lot of code here, but your task
-is only to implement code generation for Amy expressions within
-`codegen/CodeGen.scala`.
-
--   `wasm/Instructions.scala` provides types that describe a subset of
-    WebAssembly instructions. It also provides a type `Code` to describe
-    sequences of instructions. You can chain multiple instructions or
-    `Code` objects together to generate a longer `Code` with the `<:>`
-    operator.
--   `wasm/Function.scala` describes a wasm function.
-    -   `LocalsHandler` is an object which will create fresh indexes for
-        local variables as needed.
-    -   A `Function` contains a field called `isMain` which is used to
-        denote a main function without a return value, which will be
-        handled differently when printing, and will be exported to
-        JavaScript.
-    -   The only way to create a `Function` is using `Function.apply`.
-        Its last argument is a function from a `LocalsHandler` to
-        `Code`. The reason for this unusual choice is to make sure the
-        Function object is instantiated with the number of local
-        variables that will be requested from the LocalsHandler. To see
-        how it is used, you can look in `codegen/Utils.scala` (but you
-        won\'t have to use it directly).
--   `wasm/Module.scala` and `wasm/ModulePrinter.scala` describe a wasm
-    module, which you can think of as a set of functions and the
-    corresponding module headers.
--   `codegen/Utils.scala` contains a few utility functions (which you
-    should use!) and implementations of the built-in functions of Amy.
-    Use the built-ins as examples.
--   `codegen/CodeGen.scala` is the focus of the assignment. It contains
-    code to translate Amy modules, functions and expressions to wasm
-    code. It is a pipeline and returns a wasm Module.
--   `codegen/CodePrinter.scala` is a Pipeline which will print output
-    files from the wasm module.
-
-### The cgExpr function
-
-The focus of this assignment is the `cgExpr` function, which takes an
-expression and generates a `Code` object. It also takes two additional
-arguments: (1) a `LocalsHandler` which you can use to get a new slot for
-a local when you encounter a local variable or you need a temporary
-variable for your computation. (2) a map `locals` from `Identifiers` to
-locals slots, i.e. indices, in the wasm world. For example, if `locals`
-contains a pair `i -> 4`, we know that `get_local 4` in wasm will push
-the value of i to the stack. Notice how `locals` is instantiated with
-the function parameters in `cgFunction`.
-
-## Skeleton
-
-As usual, you can find the skeleton for this lab in a new branch of your
-group\'s repository. After merging it with your existing work, the
-structure of your project `src` directory should be as follows:
-
-    src/amyc
-     ├── Main.scala                (updated)
-     │
-     ├── analyzer   
-     │    ├── SymbolTable.scala
-     │    ├── NameAnalyzer.scala
-     │    └── TypeChecker.scala
-     │
-     ├── ast
-     │    ├── Identifier.scala
-     │    ├── Printer.scala
-     │    └── TreeModule.scala
-     │
-     ├── bin
-     │    └── ...
-     │
-     ├── codegen                  (new)      
-     │    ├── CodeGen.scala
-     │    ├── CodePrinter.scala
-     │    └── Utils.scala
-     │
-     ├── interpreter
-     │    └── Interpreter.scala
-     │
-     ├── lib
-     │    ├── scallion_3.0.6.jar
-     │    └── silex_3.0.6.jar
-     │
-     ├── parsing
-     │    ├── Parser.scala
-     │    ├── Lexer.scala
-     │    └── Tokens.scala
-     │
-     ├── utils
-     │    ├── AmycFatalError.scala
-     │    ├── Context.scala
-     │    ├── Document.scala
-     │    ├── Pipeline.scala
-     │    ├── Position.scala
-     │    ├── Reporter.scala
-     │    └── UniqueCounter.scala
-     │
-     └── wasm                     (new)
-          ├── Function.scala
-          ├── Instructions.scala 
-          ├── ModulePrinter.scala
-          └── Module.scala
-
-## Deliverables
-
-You are given **2 weeks** for this assignment.
-
-Deadline: **Thursday December 2 at 11 pm.**.
-
-Submission: one team member submits a zip file submission-groupNumber.zip to the [moodle submission page](https://moodle.epfl.ch/mod/assign/view.php?id=1181848).
-
-Your submission only needs to contain your `src` directory. 
-You can use the following command (from the root of your repository) to generate the archive:
-```
-zip -r submission-<groupNumber>.zip src/
-```
-
-You can then verify the content of the archive using `unzip -l submission-<groupNumber>.zip`

labs/labs_06.md

-# Labs 06: Compiler extension project
-
-You have now written a compiler for Amy, a simple functional language.
-The final lab project is to design and implement a new functionality of
-your own choice on top of the compiler you built so far. In preparation
-for this, you should aim to learn about the problem domain by searching
-the appropriate literature. The project includes:
-
--   designing and implementing the new functionality
--   documenting the results in a written report document
-
-This project has several deadlines, detailed below. Please note that the
-first of them (choosing the topic) is already coming up on Sunday!
-
-## Selecting a Project Topic
-
-**Deadline: Friday November 26th**
-
-In the following document, we list several project ideas, but you should
-also feel free to submit your own. All groups will rank the
-projects in order of preference, and we will then do our best to assign
-the preferred projects to as many groups as possible. Because not all
-projects are equally difficult, we annotated each of them with the
-expected workload. The suggested projects cover a wide range of
-complexity, and we will evaluate your submissions with that complexity
-in mind. For instance, for a project marked with `(1)` (relatively low
-complexity) we will be expecting a polished, well-tested and
-well-documented extension, whereas projects on the other end (`(3)`) may
-be more prototypical. For all submissions, however, we require that you
-deliver code that compiles and a set of example input files that
-demonstrate the new functionality.
-
-[Project ideas](labs06_material/extensions.pdf)
-
-To announce your preferences, [please fill out this form before the deadline](https://docs.google.com/forms/d/1EqRwNb61ndyTW31bmn_VellCHHTMmaaOPYSiPGbgaKw/edit). You\'ll have to
-provide **the names of the top exactly 5** projects you would like to
-work on, in order of descending preference. We will do our best to
-assign you the project you are most interested in.
-
-## Project Orientation
-
-**Deadline: Thursday December 9th**
-
-We will try to inform you about the project assignment as soon as possible. We ask you to be **proactive** and validate with the assistants your understanding of the project goals and the expectations of the end product. Think about the following questions and feel free to ask the assistants about them:
-
--   What are the features you will add to the compiler/language?
--   What would be some (short) programs highlighting the use of these features?
--   What changes might be required in each compiler phase and/or what new phases would you add? (Very roughly)
-
-
-## Project Presentation
-
-You will present your idea during the lab sessions on the last regular
-week of the semester (Dec 16th/22nd/23rd). We'll announce the concrete
-schedule of presentations at a later point. [Instructions on what and
-how to present your project can be found here.](labs06_material/presentation.md)
-
-## Project Implementation and Report
-
-**Deadline: TBD**
-
-Your implementation and a report are due on this date, and both will be
-delivered using Git. You will develop your project on top of your
-implementation of Amy. Please push all development on a new branch
-`lab06`, ideally building on top of the codegen lab (branch `lab05`). 
-**TODO: define submission method**
-
-Your repository should contain:
-
--   Your implementation, which must, to be graded at all, compile and be
-    able to run non-trivial examples.
--   A subdirectory `extension-examples/` which includes some examples
-    that demonstrate your compiler extension in action.
--   A subdirectory `report/` which includes a PDF summarizing your
-    extension.
-
-**If you did not manage to complete your planned features, or they are
-partially implemented, make this clear in your report!**
-
-You are encouraged to use the following (LaTeX) template for your
-report:
-
--   [LaTeX sources](labs06_material/report-template.tar.gz)
-
-A PDF version of the template with the required section is available
-here:
-
--   [PDF Example](labs06_material/report-template.pdf)
-
-Although you are not required to use the above template, your report
-must contain at least the sections described in it with the appropriate
-information. Note that writing this report will take some time, and you
-should not do it in the last minute. The final report is an important
-part of the compiler project. If you have questions about the template
-or the contents of the report, make sure you ask them early.
-
-A common question is \"how long should the report be?\". There\'s no
-definitive answer to that. Considering that the report will contain code
-examples and a technical description of your implementation, it would be
-surprising if it were shorter than 3 pages. Please try to stay within 6
-pages. A concise, but well-written report is preferable to a long, but
-poorly-written one.

labs/labs_setup.md

-# Labs Setup
-
-This page contains instructions on how to set up your computer to work on assignments.
-
-
-## Step 0: Find a group
-
-All work in this year's edition of CS-320 will be done in groups of two students.
-If you are looking for teammates, please consider using the course's [Moodle](https://moodle.epfl.ch/course/view.php?id=4241) forums.
-One of you should then submit the SCIPER numbers and names of all teammates through [this form](https://docs.google.com/forms/d/18-NX9JvzAVcyUwLruJ-rbkqGD-1qD8EYS_uqAFkC6NQ/edit). Note that you need access the form with epfl email account.
-By the end of the first week you *must* have registered in a group, so you can start working on the lab 1.
-
-
-## Step 1: Version control 
-
-Since you will be working with others throughout the course, we provide all labs via Git repositories.
-Once you have registered as a group, you will be assigned a repository on [EPFL's GitLab](https://gitlab.epfl.ch/).
-For every new lab we are going to push the starter code ("skeleton") on a separate branch of that repository.
-Since all labs starting from the second are cumulative, you should ideally merge your work resulting from the preceding, completed lab into the starter code of the new lab.
-Once the deadline for a lab comes around, we will simply consider your most recent commit on the respective branch as your submission.
-
-
-## Step 2: Java / Scala / SBT 
-
-We will be using Scala 3 to implement our compiler project.
-Please make sure your system is running at least Java 8 and has [SBT](http://www.scala-sbt.org/) (the default build tool for Scala) installed.
-
-
-## Step 3: Working on the labs 
-
-Once you have formed a group and installed SBT, you are ready to start the labs. The workflow for each assignment is roughly as follows:
-  * Check out the branch of the current lab from your repository. Merge with your work from prior labs (when starting work on lab 3, 4 or 5).
-  * Run ''compile'' from inside SBT to make sure your build still succeeds. If you run ''test'' at this point it should fail on some of the new tests provided by us.
-  * Implement the assignment according to the specification. Throughout the semester we will be providing you with details on each specific assignment.
-  * Once you are happy with your solution, make sure one of the team members packages the solution as a zip file with the name **submission-groupNumber.zip**. For instance, if your group number is 3, you would package the lab into a file submission-3.zip. Then go on moodle and send the file in the corresponding assignment.