I built AXIS as a learning project in compiler design. It compiles directly to x86-64 machine code without LLVM, has zero runtime dependencies (no libc, direct syscalls), and uses Python-like syntax.
Currently Linux-only, ~1500 lines of Python. All test programs compile and run. The one-line installer works: curl -fsSL https://raw.githubusercontent.com/AGDNoob/axis-lang/main/ins... | bash
It's very early (beta), but I'd love feedback on the design and approach!
Yeah that's fair. It's got "fn main()", types like "i32", and uses braces. More Rust-like than Python to be honest. The "Python-like" part is mostly wishful thinking about readability. Should've just called it "minimalist systems language" or something
Indent-based syntax is relatively simple to parse. You basically need two pieces of state: are you in indent-sensitive mode (not inside a literal, not inside a parenthesized expression), and what indentation did the previous line have. Then you can easily issue INDENT and DEDENT tokens, which work exactly like "{" and "}". The actual Python parser does issue these tokens.
Actually Haskell has both indent-based and curlies-based syntax, and curlies freely replace indentation, and vice versa (but only as pairs).
Yeah braces made the parser way simpler for a first attempt. Significant whitespace is on the maybe-list but honestly seems scary to implement correctly
I feel like Python-style indentation should be much easier to parse intuitively (preprocess the line, count leading levels of indentation) than by fully committing to formal theory. Not theoretically optimal and not "single-pass" but is that really the bottleneck?
Yeah, that’s fair. Conceptually it’s not that hard if you’re willing to do a proper preprocess pass and generate INDENT and DEDENT tokens. For this first version I mostly optimized for not shooting myself in the foot, braces gave me very explicit block boundaries, simpler error handling, and a much easier time while bringing up the compiler and codegen. Significant whitespace is definitely interesting long term, but for a v0 learning project I wanted something boring and robust first. Once the core stabilizes, revisiting indentation based blocks would make a lot more sense
Might I suggest that now is a good time to try and make a concrete wish-list of syntax features you'd like to see, and start drafting examples of how you'd like the code to look?
It's my belief that the author has almost entirely used an LLM to put this together. Tailor engagement accordingly.
How do you know this? It looks more like some kid’s homework
> 4. No Magic – No hidden allocations, no garbage collector, no virtual machine
I assume also "5. No stdlib"? Will it be even able to print("Hello world") not by doing a direct write() syscall?
I built AXIS as a learning project in compiler design. It compiles directly to x86-64 machine code without LLVM, has zero runtime dependencies (no libc, direct syscalls), and uses Python-like syntax. Currently Linux-only, ~1500 lines of Python. All test programs compile and run. The one-line installer works: curl -fsSL https://raw.githubusercontent.com/AGDNoob/axis-lang/main/ins... | bash It's very early (beta), but I'd love feedback on the design and approach!
Where is the "python syntax"?
I suspect that was in the initial prompt that was used to generate this and the LLM decided Rust syntax was preferable.
Yes, it looks almost exactly like Rust. Expectations violation! :)
Yeah that's fair. It's got "fn main()", types like "i32", and uses braces. More Rust-like than Python to be honest. The "Python-like" part is mostly wishful thinking about readability. Should've just called it "minimalist systems language" or something
I was hoping for no {}, just indentation, but ...
Indent-based syntax is relatively simple to parse. You basically need two pieces of state: are you in indent-sensitive mode (not inside a literal, not inside a parenthesized expression), and what indentation did the previous line have. Then you can easily issue INDENT and DEDENT tokens, which work exactly like "{" and "}". The actual Python parser does issue these tokens.
Actually Haskell has both indent-based and curlies-based syntax, and curlies freely replace indentation, and vice versa (but only as pairs).
Yeah braces made the parser way simpler for a first attempt. Significant whitespace is on the maybe-list but honestly seems scary to implement correctly
I feel like Python-style indentation should be much easier to parse intuitively (preprocess the line, count leading levels of indentation) than by fully committing to formal theory. Not theoretically optimal and not "single-pass" but is that really the bottleneck?
Yeah, that’s fair. Conceptually it’s not that hard if you’re willing to do a proper preprocess pass and generate INDENT and DEDENT tokens. For this first version I mostly optimized for not shooting myself in the foot, braces gave me very explicit block boundaries, simpler error handling, and a much easier time while bringing up the compiler and codegen. Significant whitespace is definitely interesting long term, but for a v0 learning project I wanted something boring and robust first. Once the core stabilizes, revisiting indentation based blocks would make a lot more sense
Fair enough.
Might I suggest that now is a good time to try and make a concrete wish-list of syntax features you'd like to see, and start drafting examples of how you'd like the code to look?