# Compiler Construction PA3 Worklog


## Team:
**Apoorva Ranade**(ar6496)&nbsp;&nbsp;&nbsp;**Sanjar Ahmadov**(sa5640)&nbsp;&nbsp;&nbsp;**Yinqi Sun**(ys3540)
<br>


## Challenges:
 -  Nested structures were a challenge. A function inside a function/class needs us to build correct scoping as well as dealing with dependencies.
    -  This is dealt by the class:StackVarRuntimeInfo and function:getStackVar. Static links were maintained in the call stack for each function to access stack frames of previous function.
 -  Handling Strings was difficult as storage and access was more complex than lists.
    -  In order for us to easily determine the correctness, we intentionally matches the error messages to the reference implementation.
 -  Creation and use of objects was a major challenge.
    -  Objects required allocation of space on the heap and access to each object required dereferencing the pointer to the objects.
 -  Testing various scenarious with similarly defined variables were time consuming. Instead, we defined certain set of variables in the beginning of the student contributed test programs, and then used the same variables throughout the programs to cover various bad and good scenarious.
 -  Another challenge was to come up with good test cases to have a broader cover. Our approach to this issue was investigating Type Checking rules and writing adverse code to those rules to see if our analyzer can make correct inferences. 
 -  Syncornizing the implementation was extra challening for pa3 compared to previous ones. Reason was the flexbility and freedom of the code generation step. Our RISC-V code did not need to match the one generated by reference compiler though we tried to get as close to it as we can. 
 	- Agreeing on the common interfaces and behavior of the compiler was necessary to make synchronization easier.
## Improvements: 
  - More checks and error messages like checking if formal parameter type does not match corresponding expression type.
  - Added more tests to rigorously check program flow. And a test(diff.py) to show a case where our implementation showed better recoverability compared to the reference compiler.
  - Added extra error state to the compiler if the actual parameter and formal parameter of the function can not resolve to a type. For example, if function expects an integer type parameter while the caller passes in a string typed param then our compiler will warn the user accordingly