Make it your own. Everything in ESPL1000 is created with extendability and modularity in mind. The transpiler is composed of multiple small programs which can be used and modified independently. They communicate with easy-to-understand formats.
I made this decision to simplify the parsing of code and also because it makes code easier to read, as there is nothing that's 'hidden' away in some macro.
ESPL1000 is a learning Project for me so anything might change whenever.
I chose strict evaluation over lazy evaluation because lazy evaluation is harder to reason about as a programmer, in my opinion.
This greatly simplifies the parser.
This simplifies development as there are many tools available for C development.
In my opinion, it does not make sense to force unneccessary indentation on people. The name of the file is the namespace of a translation unit in ESPL1000. structs and methods can be declared and defined directly, without needing a wrapper like a class or namespace construct. This also makes code easier to read without context.
There are no nested method definitions or nested structures in ESPL1000. Indentation is limited to the minimum necessary. I have personally never seen a case where it was necessary or 'better' in any way to declare a nested function or anything like that.
ESPL1000 provides the basic building blocks like loops and if-statements that are classics to most programming languages. Extra stuff like annotations or bloated syntax is avoided whenever possible.
Having 'NULL' makes it hard to understand code without context and knowledge of the code around it. Good code should make sense on it's own. So it should be obvious when a variable might not contain anything. So NULL will not be implemented in ESPL1000.
ESPL1000 has no ability to declare any global variables. Everything is (currently) either inside a struct or method.
This feature is not complete yet. It would be desireable to let the transpiler figure out if a given variable can be proven to have been assigned to before usage. This should also be true for struct members.
Properties of primitive variables should be propagated throughout the code so we can use static assertions to safeguard our code against faulty values at compile-time. This exciting feature is waiting for a concept for implementation currently.
A function declared pure should not contain calls to impure methods. Purity of a subroutine should be checked by the transpiler.