Just thought to expounds on why I was discussing the Melosynthos in prior post with some contexts:

I have written a GUI Toolkit for Linux that leveraged Vulkan to replace GTK and QT5/6.

I originally wrote it for Crypto-Trading software that can support millisecond-by-millisecond trading and update feeds, it literally have a graph supporting over 1 billion data points without any lag and it become incredibly easy to add any number of indicators to evaluate the graph. So naturally, I was looking to expand the GUI Toolkit I wrote, but as you probably imagine, trying to write code like these:

Get exhausting fast, because literally every single event, property, or method you add to a given class, would need about 50+ lines of code for it. Macro would not solve or alleviate the problem either, because it would only obscure the problem further.

The reasons why I attempted to write it in C is that it needed to be low level, it need to be fast, and it needed to be accessible to ALL programming languages through Foreign Function Interface. I wanted to make sure that no matter what programming language you choose, you could expand the GUI Toolkit by adding your own custom window, GUI control, or whatever.

That what led me to theorizing about extending C Language through dialects where you have an higher level abstracted C language transpile down to raw, but still readable C language code and not only that, but also to generates something like Foreign Function Interface JSON file so that other programming languages could quickly generate binding for the GUI Toolkit library. Hence the Melosynthos project was came up with and reiterated as I work on designing it.

So basically my roadmap is something like this:

1. Melosynthos - Compiler Generator
2. Machine Learning Shader Language (To replace HLSL/GLSL)
3. Create Dialects for C Language aka SpectraC (Object Oriented Programming, Generic, and so forth)
4. Rewrite GUI Toolkit in SpectraC
5. Potentially Fork X11/XServer as I have gained some experience and understanding on how X11/Wayland compositors work internally.

As you can imagine, a lot of different personal projects, but each can be used to help create the other project.

Here the video demo of GUI Toolkit

My other side project that I am struggling to find time is to write books, particularly on C programming sometime and you can read them here.

The craziest idea for a project by far is probably trying to come up with "X25" as an evolution from X11, instead of XServer being it's own independent process, it would be rewritten as a software library in C so that every window manager/compositor could use the same central implementation and gain all of the feature set that the library offers rather than fragmented ecosystem like Kwin/Gnome/Wlroots. I don't have much confidence with Wayland and it have remained broken for literally decades with a lot of contention between developers on how to best approach each problem in wayland.

Anyway, let me know if you are interested in more discussion on any of the projects above. That pretty much sum up my vision for Linux, rewriting the GUI stack and Window Compositor one day and hopefully re-approach C Programming in general to make it easier, but offers some memory/type safety.

This thread delves into contemplating the concept of "Melosynthos," more aligned towards being a compiler generator rather than strictly a parser generator.

Initially, I was engrossed in a Python Lark fork while concurrently developing an unique shader language, primarily for Vulkan Compute (SPIR-V, to be precise), aiming at Machine Learning (intending to replace the Pytorch framework). Python Lark's parser generator appealed to me due to its simplicity-centric grammar syntax, prompting me to create a fork in C language. This new version was designed to support a top-down LL(k) parser algorithm and generate corresponding AST trees.

Upon successfully getting it to function, it dawned on me how complex and challenging the iterative development of a compiler could be. The task of designing a programming language and writing the compiler implementation, along with the eventual Language Server Protocol, seemed daunting for a single developer.

This realization sparked the question - could we streamline the entire process, right from the parser generator to the compilation output target? This led to the inception of the Meta-AST and subsequently, the Melosynthos project.

The Meta-AST scripting language is essentially conceptualized to interact with the generated raw AST tree, providing traversal and visitor syntax. This enables users to enhance, refine, or rectify the "Raw" AST with more comprehensive data, such as type information or context-free grammar support.

The Melosynthos compiler generator project primarily involves three stages: the standard Backus-Naur Form grammar for generating Lexer/Parser and raw AST, the Meta-AST script interacting with the AST, and the final compilation output reading the AST and printing it out.

Envision a scenario where everything is streamlined from the start, enabling the generation of any dialects or features in the language as a full compiler in the output, accompanied by an LSP server. Despite searching extensively, I couldn't find any existing tools to accomplish this.

Consequently, I began musing about the potential structure and function of Meta-AST, emphasizing its readability and familiarity for compiler designers. It borrows elements from Regex (like "^" for the start of an array and "$" for the end), functional programming for pure function transformation and analysis, and differentiation between "dialects."

Consider the following example of an AST tree represented in JSON:

{
    "rule": {
        "HELLO": { "Content": "Hello", "Line": "1", "Col": "1" },
        "WORLD": { "Content": "World", "Line": "1", "Col": "6" },
        "SET_OF_EXCLAIMATION_MARK": [
            { "EXCLAIMATION_MARK": { "Content": "!", "Line": "1", "Col": "12"} },
            { "EXCLAIMATION_MARK": { "Content": "!", "Line": "1", "Col": "13"} },
            { "EXCLAIMATION_MARK": { "Content": "!", "Line": "1", "Col": "14"} }
        ]
    }
}

For a basic analysis of this AST tree, we could attribute the AST with the following script:

local myAST = .; // You are making a copy of the current AST
myAST.rule.SET_OF_EXCLAIMATION_MARK.summarize(
    MarkCount = this.Count,
    StartColumn = this[^].Col,
    EndColumn = this[$].Col,
    StartLine = this[^].Line,
    EndLine = this[$].Line
);

This would add counts for exclamation marks, start and end columns for this particular rule in the grammar, and the start and end lines for diagnostic purposes.

I share this here to muse over the concept and encourage some discussions surrounding it. I hope it sparks some interests in this topic.