================================ 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.
Dezzmeister/group-x-compiler
Compiler for a general purpose language called "X". Designed and built as a semester-long project for a compilers class
C++