Show HN: Axis – A systems programming language with Python syntax

rzzzwilson 5 hours ago | parent | next [-]

Where is the "python syntax"?

hresvelgr 4 hours ago | parent | next [-]

I suspect that was in the initial prompt that was used to generate this and the LLM decided Rust syntax was preferable.

	▲	metadat 4 hours ago \| parent [-]
		Yes, it looks almost exactly like Rust. Expectations violation! :)

▲

AGDNoob 5 hours ago | parent | prev [-]

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

▲

rzzzwilson 5 hours ago | parent [-]

I was hoping for no {}, just indentation, but ...

▲

nine_k 4 hours ago | parent | next [-]

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).

	▲	pansa2 2 hours ago \| parent [-]
		> You basically need two pieces of state That’s enough for INDENT, but for DEDENT you also need a stack of previous indentation levels. That’s how, when the amount of indentation decreases, you know how many DEDENTs to emit. The requirement for a stack means that Python’s lexical grammar is not regular.

▲

AGDNoob 5 hours ago | parent | prev [-]

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

▲

zahlman 4 hours ago | parent [-]

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?

▲

AGDNoob 4 hours ago | parent [-]

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

	▲	zahlman 4 hours ago \| parent [-]
		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?

▲

AGDNoob 5 hours ago | parent | prev | next [-]

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!

▲

hresvelgr 4 hours ago | parent | prev | next [-]

It's my belief that the author has almost entirely used an LLM to put this together. Tailor engagement accordingly.

▲

kej 3 hours ago | parent | next [-]

It's definitely odd that someone who allegedly wrote a complete compiler in Python would describe something that is obviously Rust syntax as Python-like.

▲

AGDNoob 2 hours ago | parent [-]

I totally agree. "Python-like" was a bad choice of words on my part. I meant it more in terms of learning curve and explicitness, not the surface syntax. Structurally its more like C/Rust and I should have said that from the start

	▲	volemo 36 minutes ago \| parent [-]
		Could you tell us, did you, or did you not, use "AI" in creating this project?

▲

didip 4 hours ago | parent | prev [-]

How do you know this? It looks more like some kid’s homework

	▲	2 hours ago \| parent [-]
		[deleted]

▲

nine_k 4 hours ago | parent | prev | next [-]

> 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?

	▲	AGDNoob 3 hours ago \| parent [-]
		Right now there’s intentionally no stdlib, so yes, printing would ultimately boil down to a direct write syscall. The idea is that the core language stays as thin as possible and anything higher level lives on top of that, either as compiler intrinsics or a very small stdlib later. For the MVP I wanted to make the boundary explicit instead of pretending there’s no syscall underneath. So “Hello world” will work, but in a very boring, low level way at first

▲

Panzerschrek 2 hours ago | parent | prev [-]

It looks like yet another C-like language with same problems C has, notably memory-safety.

	▲	volemo 37 minutes ago \| parent [-]
		The author's said it's "a learning project in compiler design", so I guess solving problems of C wasn't one its goals.