I guess in the future, we can write our own diagnostics emission library, so that we can get rid of throwing Java exceptions.

C

Current situation

I think commits messages in the repository at the moment aren't great - they are not descriptive and in most cases it's easy to get confused.

Conventional Commits

I suggest using conventional commits which are a way to standardize commit messages. Here is an example of how they are used in my repository:

As you can see commit messages are more descriptive and now make some kind of sense.

Conventional Commits Standart also applies to the commit's footers and description.

I think using them will make it easy to work asynchronously and resolve merge conflicts, track progress, or just see the project's history.

Here are some resources on the topic:

Conventional Commits Specification.
Conventional Commits: A Better Way.
Another Conventional Commits Article.

Возможность разделить программу на несколько файлов, чтобы весь код не был в одном файле. Это улучшит организацию и структуру проекта.

Как это будет выглядеть:

main.lzr

using "./myModule"

greet("Hamlet")

myModule.lzr

func greet(name) {
    print("Hello " + name + "!")
}

I don't think it is a great decision to put evaluation logic into AST classes. Maybe create a separate from ast package classes for that, for easier process of adding new builtin types into the language?

Also it will be easier, if the language is going to have a VM later. Because the logic for VM bytecode emitting is going to be in different classes.

1. Spelling mistakes

In com.kingmang.lazurite.lib i see ..Exeption class names all around, which isn't actually correct spelling of word Exception.

- public final class _AExeption extends RuntimeException
+ public final class _AException extends RuntimeException
- public final class _LExeption extends RuntimeException
+ public final class _LException extends RuntimeException
...

2. Confusing exception names

Also exception names seem really confusing for me. What is _AExeption, _LExeption, _PExeption, etc.? They should really be renamed.

3. Names of storage classes

Functions, ClassDeclarations, Classes are also a bit confusing. In my opinion, it is better to use Storage, Resolver or Manager postfix:

- Functions
+ FunctionManager
- Classes
+ ClassManager

- Functions
+ FunctionStorage
- Classes
+ ClassStorage

- Functions
+ FunctionResolver
- Classes
+ ClassResolver

4. Utility classes

Take for instance a utility class, related to function arguments:

public final class Arguments {

    private Arguments() { }

    public static void check(int expected, int got) {
        if (got != expected) throw new _AExeption(String.format(
                "%d %s expected, got %d", expected, pluralize(expected), got));
    }

    public static void checkAtLeast(int expected, int got) {
        if (got < expected) throw new _AExeption(String.format(
                "At least %d %s expected, got %d", expected, pluralize(expected), got));
    }

    public static void checkOrOr(int expectedOne, int expectedTwo, int got) {
        if (expectedOne != got && expectedTwo != got)
            throw new _AExeption(String.format(
                    "%d or %d arguments expected, got %d", expectedOne, expectedTwo, got));
    }

    public static void checkRange(int from, int to, int got) {
        if (from > got || got > to)
            throw new _AExeption(String.format(
                    "From %d to %d arguments expected, got %d", from, to, got));
    }

    private static String pluralize(int count) {
        return (count == 1) ? "argument" : "arguments";
    }
}

Maybe use Utilities, Utils or Helper postfix?

- public final class Arguments {
+ public final class ArgumentUtilities {

- public final class Arguments {
+ public final class ArgumentUtils {

- public final class Arguments {
+ public final class ArgumentHelper {

Case inconstancy

In COUT_Setting, underscore creates case inconstancy with other names like AbstractVisitor or Console:

- public class COUT_Setting implements OutputSettings {
- public class SOUT_Setting implements OutputSettings {

It can also be seen in module names:

- Arrays
+ arrays
- GForms
+ gforms
- HTTP
+ http
java
- LFS
+ lfs
...

SOUT_Setting can be renamed to something like StringOutSetting, I have no idea at the moment.

Plural and singular nouns

Going back to the previous code spinnet, COUT_Setting implements OutputSettings, which in my opinion creates the plural/singular inconstancy.

It can again be seen in module names:

- Arrays
+ array
- GForms
+ gform
- HTTP
+ http
java
- LFS
+ lfs
...

Progress

• Implement enum statement parsing.
• Put enum type into the evaluation logic.

Instead of storing executables right in the repository source code, you can just use releases tab in the GitHub. It also allows you to store executables for different versions of your project. WDYT?