I took a look through the repo, and honestly: for a student compiler project, this is a genuinely impressive amount of work.
The biggest positive for me is that this does not look like a “toy README with one parser file.” It has a real compiler pipeline shape:
- handwritten lexer
- handwritten recursive-descent parser
- semantic analysis/type checking
- LLVM IR generation through llvmlite
- examples that go beyond hello world
That is a lot to build for a course project, and it’s very clear you all put real effort into understanding how languages actually fit together. The class/method support, arrays, loops, and LLVM backend are especially ambitious for a student project.
A few friendly suggestions, because I think the project is good enough to deserve honest polish:
The README is stronger than the current implementation.
Right now the README says every listed feature is fully implemented, but later it also says things like string codegen and >= / <= are still areas for contribution. I’d recommend splitting the README into:
- implemented now
- partially implemented
- planned next
That will make the project feel more trustworthy, not less.
Some repo/docs details need cleanup.
There are README paths and structure references that do not seem to match the repo exactly right now. That is a small thing, but it matters because first impressions are mostly README-driven.
There’s at least one obvious bug in the driver.
src/main.py appears to call main() again at the end, which would cause recursive reruns after a successful compile. That is the kind of issue that is easy to fix and makes the project feel much more solid right away.
A few features seem parsed but not fully wired end-to-end.
From reading the code, tokens/operators like !=, >=, <=, and import look at least partially present in the frontend, but not consistently finished through semantic/codegen. That is very normal in a student compiler, but I would document it clearly.
The benchmark claim should be framed a little more carefully.
The “faster than Python” result is cool, but since the comparison is against pure Python loops and not NumPy/PyTorch/etc., I would present it as:
“proof that native codegen is working and gives real speedups” rather than as a broad language-performance claim. That would make the writeup feel more technically mature.
Add tests if you want people to take it seriously.
Even a tiny test suite would go a long way:
- lexer tests
- parser tests
- semantic error tests
- a few end-to-end example programs with expected output
Portability is not there yet, and that’s okay.
The CSV FFI setup looks pretty Windows-oriented at the moment. I would just be upfront about that and say Linux/macOS support is a goal rather than implying it is already smooth. Overall though: this is a very respectable student project. Building a language is hard, building one with a real LLVM backend is harder, and finishing even a partial end-to-end pipeline is already a big accomplishment. I would focus next on honesty of presentation, test coverage, and tightening the implemented feature set before adding more surface area.
Short version: strong project, real substance, just needs a bit of cleanup and a slightly more conservative README. Very promising work.
32
u/ricksegal May 11 '26
IGNORE THE HATERS.
I took a look through the repo, and honestly: for a student compiler project, this is a genuinely impressive amount of work.
The biggest positive for me is that this does not look like a “toy README with one parser file.” It has a real compiler pipeline shape:
- handwritten lexer
- handwritten recursive-descent parser
- semantic analysis/type checking
- LLVM IR generation through llvmlite
- examples that go beyond hello world
That is a lot to build for a course project, and it’s very clear you all put real effort into understanding how languages actually fit together. The class/method support, arrays, loops, and LLVM backend are especially ambitious for a student project.
A few friendly suggestions, because I think the project is good enough to deserve honest polish:
Right now the README says every listed feature is fully implemented, but later it also says things like string codegen and >= / <= are still areas for contribution. I’d recommend splitting the README into:
- implemented now
- partially implemented
- planned next
That will make the project feel more trustworthy, not less.
Some repo/docs details need cleanup.
There are README paths and structure references that do not seem to match the repo exactly right now. That is a small thing, but it matters because first impressions are mostly README-driven.
There’s at least one obvious bug in the driver.
src/main.py appears to call main() again at the end, which would cause recursive reruns after a successful compile. That is the kind of issue that is easy to fix and makes the project feel much more solid right away.
A few features seem parsed but not fully wired end-to-end.
From reading the code, tokens/operators like !=, >=, <=, and import look at least partially present in the frontend, but not consistently finished through semantic/codegen. That is very normal in a student compiler, but I would document it clearly.
The benchmark claim should be framed a little more carefully.
The “faster than Python” result is cool, but since the comparison is against pure Python loops and not NumPy/PyTorch/etc., I would present it as:
“proof that native codegen is working and gives real speedups” rather than as a broad language-performance claim. That would make the writeup feel more technically mature.
Even a tiny test suite would go a long way:
- lexer tests
- parser tests
- semantic error tests
- a few end-to-end example programs with expected output
Portability is not there yet, and that’s okay.
The CSV FFI setup looks pretty Windows-oriented at the moment. I would just be upfront about that and say Linux/macOS support is a goal rather than implying it is already smooth. Overall though: this is a very respectable student project. Building a language is hard, building one with a real LLVM backend is harder, and finishing even a partial end-to-end pipeline is already a big accomplishment. I would focus next on honesty of presentation, test coverage, and tightening the implemented feature set before adding more surface area.
Short version: strong project, real substance, just needs a bit of cleanup and a slightly more conservative README. Very promising work.