28 days later...
26/06/2023
After another chat with mate he was asking what it is I like about certain langs.
After another chat with mate he was asking what it is I like about certain langs.
For me I'm sort of a mid-typed lang guy. I love how loose PHP is and how easy it is for others to pick up and learn. Same with the likes of Python but I'm not a tabby format guy. Don't get me wrong I tab the hell out of my code when writing but that catches me out with Python.
I'm also a big OOP fan, and I do love typecasting when working in big teams to help keep track of what's what. So this got me thinking about redesigning the syntax.
My mate also made a comment on how he likes to parse, he just looks for characters rather than parsing a full line for example. That really piqued my interest! So I thought I'd redesign the parser as well.
We were talking about duck typing languages. I'll admit I couldn't remember what the hell that meant. I thought only monkeys could type, right?
But he explained the term to me and I remembered the concept.
Did I tell you my brain doesn't retain words? And I became a developer, go figure lol.
I sort of don't see words I kind of visualise what I'm after in my head and often have to look up the spellings...it's a pain but it's the brain God gave me, what I have to put up with till Musk creates the brain interface.
So on the drive home my brain was high on crack again formulating the new syntax.
The concept is to not have a traditional OOP lang but more a functional one that emulates, for want of a better word, OOP design methods. So to build a 'class' you just create a function with functions in it. Ain't that what classes are? Pissy dev guy, mail me your response to mike-is-right@kytschi.com and THAT'S THAT!
It's just words Mwan!
So this is now what I'm thinking the syntax is going to be:-
HelloWorld {
print "Hello World!";
FlatEarth {
print "The Earth Is Flat, and That's That!";
InnerEarth {
print "Hello From Inner Earth!";
}
InnerEarth();
}
FlatEarth();
}
But but...typecasting!
Don't worry I've got you covered!
1984 {
x:int = 2;
y:int = 2;
addNumbers:int {
return x + y;
}
print x . "+" . y . "=" . (addNumbers + 1);
}
Is this practical?
I'm not really sure to be honest.
To me it kind of makes sense. But then again my brain is an odd one, have you seen this site and my github account?
When I was writing the typecasting source it really flowed nice and quick.
Am I ripping another lang off?
Probably. Letters in the post please...
I've seen that many over my time there'll be bleeding of all kinds in that. But for now I like it!
The parser rebuild
With me having the lang loose and it just figures out what is what as it's compiling or at runtime, this really simplified the parser code for building the AST. I mean really simplified it!
I went from about 1000 lines of code and like 22 source files, to around 200 lines and 6 source files. And the speed improvement really showed.
I command thee to lift thou dress wench...
At the mo the only command set I'm working with is to print to screen.
I love this guy called Terry Davis (R.I.P. bud your missed!), creator of TempleOS and HolyC. Checkout TempleOS and HolyC if you haven't already. Sure the guy had issues (don't we all?) but you can't deny that he was a true coding genius!
Anyways I really liked his approach to printing. His print command basically would print to any kind of stream. Be it a screen or a file. This I wanted for That's That.
The command
print
will become a command for printing to screens, files, hell even stuff like database connections. Well that's the plan anyways :-P
So for now I'm just dicking around getting the AST built and then it's the decision of do I compile using something like assembly or do I use the LLVM API...