Hi guys because my project was not accepted for huggingface, I changed to Tencent: Hy3 (free), from ai.hackclub.com

OK……..I just translated almost all the python in rust. I used some AI here to boost up this things, I also wrote down some instructions for the use of the language. Hope you like it, hope you like my idea, I want someday to make this language one of the biggest. Maybe you can contact me and we can create a large community :)))

Executables

I created an app for Ubuntu, one for macOS and one for Windows.

Also

I will continue working on this language so follow me to get new updates ; )

Finally ready….. I have built the Cranelift interpreter😮‍💨😮‍💨😎😎🎉🎉. The programming language is now stable you can write some programs in it and works perfectly, out puts perfectly.

Last thing

Now to finish it I have to translate all python part into rust so I can make a stable release.

What I did

I finished the parser 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉. So what a parser do is that it takes the tokens generated by the lexer and creates structures with them, also verifying the syntax of the code. For this ⬅️⬆️ it uses the ast (Abstract Syntax Tree).

Changes of plans

I recently discovered Cranelift, that I give the structures generated by the parser and translates them in machine code, and it is way faster than my first option to write a rust interpreter that would’ve done the same thing.

So I created a lexer, it looks good, right? And now i am moving on to the next part: the parser (where I will have to verify the syntax and combine the tokens generated by the lexer in structures, named statements, that can be then translated directly into code).

In this short devlog I want to announce you the last changes in the AiRY / AiRY Core standard lib (saying this cus I am planning to add more libs after I finish this one) :

• perform became unmutable; what does that mean: when you write perform x+1 the value of x won’t be increased by one, insted you shoul write x = perform x+1

Anyway token.rs and ast.rs are ready, I am now moving on to the lexer.rs (the component that translates the input code in structures and tokens from ast.rs and token.rs)
See you soon!!!

So…..First, I made some changes in the syntax of the language:

• from now on every operation (-, +, /, *, %, &, |, ^, ~) must be preceded by perform, like perform x+1 or perform x&2

I also started to do the interpreter in rust:
-token.rs (defines every function as a word)
-ast.rs (makes structures with tokens)

Problems in interpreter till now:
-you can write just perform x+1 and not perform 1+1 , cus if you write perform 1+1 it has to return somewhere and perform x+1 just increments x with 1, but this eliminates the posibility to declare x with an operation (I mean the value), like set x perform 1+1
What do you think should I keep perform????? Anyway see you in next devlog!!

Devlog: Replacing Flower’s Old Function Syntax with func name(...): type

This feature started out as what I thought would be a straightforward syntax cleanup.

Flower’s old function syntax looked like this:

int add(a: int, b: int):
    return a + b
end

and exported functions looked like this:

prop int test():
    return 1
end

It worked, technically, but it had started to annoy me more. The biggest issue was that function declarations did not visually match the direction Flower was already heading in, and instead felt much more C-like than I wanted.

prop func create(...): Person
func main(): int

This style says “this is a function” up front, gives a clean place for modifiers like prop, and keeps the return type attached to the signature rather than awkwardly leading it.

The goal was simple:

func name(...): type

instead of:

type name(...):

Simple in theory. not so much when the compiler is written in the language being refactored.

The Problem

Flower’s parser assumes top-level function definitions start with a type. Old parser logic was built around that:

int main():

means:

1. parse a type,
2. an identifier,
3. params,
4. and a body

That assumption was scattered through a few different places:

• normal function definitions
• prop function declarations
• forward declarations
• examples and docs
• the compiler’s own source

Now, in retrospect, this was actually one of the easier changes. It didn’t take a whole lot of planning nor brain power, and I was able to change it pretty quickly. Luckily for me, I’ve built codegen to rely purely on ast values rather than shaping.

The New Shape

The new syntax is:

func add(a: int, b: int): int
    return a + b
end

and exported functions now look like:

prop func test(): int
    return 1
end

This is nicer because:

• func makes declarations immediately recognizable
• prop composes more cleanly with func
• return types now live where people expect them to
• future syntax has more room to grow without feeling backwards

It also feels more in line with Flower’s broader goals: explicit, readable, and not complex.

The Refactor

Previously, parse_func_def looked for a return type first:

type name(...):

Now it expects:

func name(...): type

So the order changed to:

1. expect func
2. parse function name
3. parse parameter list
4. expect :
5. parse return type
6. parse body until end

That part was conceptually easy.

The more annoying part was updating all the places that assumed if it isn’t a var decl and it looks like a func, it’s a func.

That fallback had to go (Good riddance!).

Instead, top-level parsing needed to become more explicit:

• prop func → exported function
• func → normal function
• forward func → forward declaration

The old one worked, but it relied on vague “anything else is probably a function” rules.

The Bootstrap Mistake

At one point, I made a bootstrap build so I could use a Flower_new binary to compile the refactored compiler. Unfortunately, I had made a mistake in parse_forward: advancing before peek checks.

Feel free to check out the bootstrapper to see why this was an issue ;)

This meant my “new compiler to compile the new compiler” was built from a broken parser.

The workaround was cursed, but it worked:

1. check out the commit before the refactor
2. fix the bug
3. compile a new binary
4. switch to the refactor branch
5. use the binary to compile the new version

Since the compiled binary was ignored by Git, this was actually fairly simple.

Not the most elegant bootstrap story, but it got the compiler to, well, compile.

Hi guys!!!! Sry for lack of devlog, I really forgot like forgot forgot. Anyway I want to announce you that my AI interpreter is ready, like it transform pretty well from Natural Language to actual code (that I decided to name AiRY Core). It also knows multiple languages (in the images below there is chinese I think) . I would like to present you what my programming language has till now: normal operations, bitwise operations, if, else, elseif, loop (like for), infloop (like while), set (declares dynamical variable). I think it is enough for now and I am going to step in and make a rust interpreter, btw I do not know rust at all. I am letting you the images below, hope you enjoy my project :)))

Hey! My name is Mihai and I just started building AiRY, a programming language where you write code in plain natural language instead of strict syntax.
The Idea
Why do you need to memorize complicated syntax just to tell a computer what to do? AiRY lets you write normal instructions in any language you want, and the system translates them into executable code called AiRY Core.
The architecture is simple: an AI layer that understands what you want to do, and a deterministic execution layer that runs the code consistently every time.
What I’ve Done So Far
I defined the initial specification of AiRY Core — basically the rules that make the language work:

set — declares a variable
show — displays a value
read — reads input
if / else / elseif — conditionals
loop — equivalent of for
infloop — equivalent of while
Basic arithmetic and logical operations

A rule system for handling errors and unsupported operations
I also integrated a language model (Gemma 4-31B via Hugging Face) that translates natural language into AiRY Core using a custom prompt system. It works surprisingly well, even with variables written in Chinese.