================================ Group X =======================================
Team:
--Komi Alasse (Language Guru)
    -Completed the LRM; contributed to the lexical analyzer, AST, TAC, and parsing 
        duties; troubleshooted testing runs and assembly code; guided sieve example code
--Alec Bailey (Test Engineer)
    -Created tests for language, contributed to AST and TAC files, helped troubleshoot
        any issues with parser; aided on presentation
--Giovanna Befeler (Manager)
    -Organized weekly group meetings to go over project, reserved rooms and ensured
        communication between group members on code dependencies, contributed to
        AST and TAC files regarding literals, created presentation
--Joe Desmond (System Architect)
    -Created parser, lexical analyzer, AST, TAC, and assembly code; helped all other 
        group members when lost; general leader of our design and teamwork on project
--Robbie Rasor (Helper)
    -Contributed to TAC, AST files regarding literals; helped formulate tests; replaced 
        semicolon syntax with period syntax; worked on dynamic array "s" feature; aided in
        sieve example code

=============================== Group X Compiler ===============================

The project uses C++ 17 with GNU extensions (-std=gnu++17). Source code and
header files are in the `src/` directory, and tests are in the `tests/`
directory (Test Engineer feel free to set this up however you want). The entry
point is main.cpp in the top level directory, and there are a few make targets
you can use to build in debug/release mode or to run tests:

make all: builds debug and release
make debug: builds debug (-Og) which has some flags enabled that make debugging
    easier
make release: builds release with flags for speed optimizations
make clean: cleans up artifacts generated by the build process

make test_debug: builds test binary in debug mode and runs it, then deletes the
    binary
make test_release: builds test binary in release mode and runs it, then deletes
    the binary. It is useful to build and test in this mode because the heavy
    optimizations ensure that undefined behavior is assumed impossible and we aren't
    relying on it
make test_all: builds debug and release test binaries, runs them, and cleans
    them up

==================================== Tests ====================================

Tests are in the `tests/` directory. The entry point for the test binary is
`tests/main.cpp`. I set this up so that individual unit tests can be written
to test different parts of the app separately. The functions to run tests are
declared `extern` in main.cpp, and are added to an array of function pointers
so that the tests can all be run in sequence. If a single test fails, then the
entire suite fails. C and C++ have assert and static assert macros that allow
us to test for conditions at runtime and compile time respectively. I wrote a
stub test using assert in `tests/stub.cpp`. This is just a start, the Test
Engineer is free to extend this, discard this, or whatever.

================================== Dev Setup ==================================

You may want to add the following line to your .vimrc:

    au BufReadPost *.ypp set syntax=yacc

This tells Vim to use yacc syntax highlighting for .ypp files.

==================================== TODOs ====================================

1. We are missing a few AST nodes and corresponding grammar rules:
    - dynamic array typename (ints, float*s)
    - import statements and export decls
    - lambda functions?
    - ternary expr has AST class but no production
    - generics

2. We need better errors in the parser. There is a "SourceErrors" object that
    gets passed to the parser, and it has vecs for type errors and parse errors.
    The typechecker fills the type errors vec as it goes through the program,
    but the parser quits and kills the entire program when it encounters an error.
    Ideally the parser would put errors in the parse errors vec, but if that's too
    much then the parser should just reject the input. If it quits the whole program,
    then 1 parse error in a test will cause the entire test runner to exit, and this
    isn't good.

3. Locations are janky - I enabled Bison locations for better error reporting,
    and they work most of the time, but sometimes the line number is a 1 or more
    lines off in the reported error

4. Three address code

5. LLVM backend? Or maybe just target linux on x86

==================================== Proposal ====================================

Java, Python, C, and C++ are core languages for many beginner programmers. There 
are certain aspects of each one that make coding easier for its users. We propose 
a general-purpose programming language inspired by Python, Java, C, and C++. Our 
language takes parts of our favorite features of these languages and puts them all 
into one language. This is hopefully a more user-friendly way for programmers to 
code in our opinion because of our specific preferences. Some examples of unique 
features to our language are ending statements with periods, our for loop as seen 
is python– looping through objects– and pattern matching. Our goal is to create an 
intuitive, easy to use general purpose language for programmers of all skill levels, 
with a combination of the most essential low and high level features.

Existing languages in this domain fall short of this goal in one or more ways. Java 
is intuitive and easy to learn, but Java’s strict programming model forces the 
programmer to model a problem in terms of objects when a different model may be more 
appropriate. Python provides many convenient high level features and is easy for new 
programmers to pick up, but Python hides many of the low level details from its users, 
and the most commonly used Python implementations are not compiled to native code and 
are therefore not as fast as compiled languages. Python’s significant whitespace is 
also unusual and unlike the other popular general purpose languages. C is a great 
general purpose language, but it lacks many features of modern languages, such as native 
support for proper objects, a “match” expression, and a standard library. C++ makes up 
for this by including many more features than most C++ programmers will ever learn and 
an extensive standard library. We want our language to have enough features to be useful 
to most people, but not too many features for programmers to learn.