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) :
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:
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!!
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.
Flower’s parser assumes top-level function definitions start with a type. Old parser logic was built around that:
int main():
means:
That assumption was scattered through a few different places:
prop function declarationsforward declarationsNow, 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 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 recognizableprop composes more cleanly with func
It also feels more in line with Flower’s broader goals: explicit, readable, and not complex.
Previously, parse_func_def looked for a return type first:
type name(...):
Now it expects:
func name(...): type
So the order changed to:
func
:
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 functionfunc → normal functionforward func → forward declarationThe old one worked, but it relied on vague “anything else is probably a function” rules.
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.
This meant my “new compiler to compile the new compiler” was built from a broken parser.
The workaround was cursed, but it worked:
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.
