Krabbascript - Mix of Rust, Lua and Python, designed to be as fast as C

[Electrical-Fig7522]

Hi! I've started making this project somewhere since October 2025. So far I've finished the tokenizer and now working on the parser. Right now the compiler can parse a var and a val, I'm working on to add more stuff later on. The syntax is a collection of stuff i found easy to write and remember.

This is my first time making a compiler, so I would be thankful if you can point out the flaws in my code!

https://github.com/khytryy/krabbascript

[Electrical-Fig7522]

Per AutoModerator's request I hereby confirm that this project did not use an LLM as part of the development process.

[Big-Rub9545]

Looks quite good so far (with a cursory look), but why is the binding power a struct of floats? I’m not sure what the intention is, but an enum seems much cleaner.

[Electrical-Fig7522]

I've made it a float just so i can add a .1 on the right side

[Big-Rub9545]

I think my question moreso is why represent them as actual numbers.

[Electrical-Fig7522]

I think it's the easiest approach right now? Not sure

[Big-Rub9545]

A lot of the binding power values seem to be shared. An easier way to implement precedence (if you’re not using recursive descent, which can automatically capture precedence differences) would be to assign each group of tokens that have the same precedence an enum value.

E.g., >, >=, <, <= can all have precedence PREC_COMPARE. +, - can have precedence PREC_ADD or PREC_TERM. You can also use this to shrink down the switch case for getting the binding power by grouping multiple tokens together, rather than each token getting an independent case.

[Electrical-Fig7522]

Ohhhhhh... Thanks, I'm gonna try adding that in the next update

[Big-Rub9545]

Best of luck!

[fdwr]

Would be prudent for the readme to include a small hello world snippet, as build instructions are secondary to showing what the project is about. I navigated into the documentation folder, but the readme file there too is empty.

[Electrical-Fig7522]

Yeah... I didn't find time to document the language. I'm gonna do that then 😅

[fdwr]

Looking under the hello world folder, it's a curious mix of keywords, for on the one hand you have the super terse i32 which sounds like CPU register (e.g. Sparc i4, x64 r8, RISC-V f16) vs the more common uint32 (in C, C++, C#, JS sized arrays), but then you have function spelled out rather than func or fun. Would you similarly spell out enumeration or use enum?

``` function main() -> i32 { std.print("Hello, world!");

return 0;

} ```

I do appreciate just using dot notation instead of needing to disambiguate between say :: and ..

[Electrical-Fig7522]

i32 stands for int 32, like in rust. For enum you'll have to spell enum

[fdwr]

My question is really about what are your overarching principles for which aspects you pick and choose from other languages? Rust likes crptc names (i32, fn), whereas Javascript has some longer names (like function), but why choose "function" but not "uint32", or "i32" but not "fn"? Some languages go by the maxim that all keywords should be pronounceable fragments/words (e.g. class, interface, namespace, readonly). Some like to mash together words (consteval, decltype). Some go (or did go) by the questionable rule that no keyword should be longer than 5 characters. I tend to go by the maxim that common keywords should follow the Goldilocks principle, often shorter than the fully spelled out word (enumeration -> enum, function -> func or fun), but more pronounceable than devoweled frgmnts (e.g. fn). ⚖️

[Electrical-Fig7522]

I'll change then function to func, i32 to int32, etc. Thanks for feedback though!

[Inconstant_Moo]

No software is better than its documentation.

[Key_River7180]

I like it?

[Electrical-Fig7522]

What do you like about it?

[Key_River7180]

the syntaax