Related work of interest

[mingodad]

Hello !

I also did some extensions and ports to CocoR:

• https://github.com/mingodad/CocoR-Typescript
• https://github.com/mingodad/CocoR-CPP
• https://github.com/mingodad/CocoR-CSharp
• https://github.com/mingodad/CocoR-Java

I'll look at your changes to see what I can also added to my versions of it, maybe it also can be useful for you to look at my extensions too.

Cheers !

[mingodad]

Looking at Coco.atg it doesn't seem that you have added/changed anything significant there, what's in your view the main advantage of your fork over the original CocoR ?

[hrumhurum]

The idea behind Turbo Coco/R revolves around a universal compiler architecture: one backend implementation (parser, DFA) with multiple frontends (code generators for target languages). In my opinion, such architecture would allow better code utilization than existing efforts. And better code utilization translates to better quality and less support efforts through the time. For instance, most contemporary Coco/R implementations use ad-hoc interval arithmetic for charsets, and this sometimes leads to idiosyncrasies of inefficiency in the generated code. But Currently the Turbo Coco/R is not there yet. If you take a closer look at the code, you can see that it is still quite hairy and thus not ready to reach the desired state of the art.

The second idea is to provide seamless integrations with various IDEs. For now, it covers MSBuild-based projects such as C# out of the box providing a good development curve.

Regarding extensions, there are not many of them in Turbo Coco/R. Most and foremost, it supports pragmas such as $namespace and $compatibility. $namespace is self-explanatory. $compatibility is a tricky one: it specifies the name and version of the tool to be compatible with. This idea behind it is to provide long-term compatibility with existing end-users' code, especially when the users dive into their own customized .frame files. We want to keep such projects buzzing without breaking them, even when Turbo Coco/R continues to evolve.

Regarding evolution, the C# code generated by all Coco/R implementation is ancient. E.g., It does not support nullability verifications, it tries to reinvent the wheels like using its own text buffer instead of a standard and versatile System.IO.TextReader etc. It would be cool to improve those aspects as well. And it will require quite a few changes in the generated code that may break the user's code. That's why there is a $compatibility pragma.

To sum it up, Turbo Coco/R is more oriented towards frictionless work in production scenarios and towards new features in target languages. Of course, it is easier said than done, but it would be cool if we could join some efforts to bring Coco/R ecosystem to an upper level.

What grammar extensions do your .atg flavors support?

[mingodad]

I just added some from https://github.com/Lercher/CocoR , see this readme https://github.com/mingodad/CocoR-CPP#cocor-for-c for an overview and also have it proted to Typescript/Javascript with an online playfround here https://github.com/mingodad/CocoR-Typescript .

There is an old fork with interesting ideas here https://github.com/charlesw1234/cocoxml it a pure C port.

[mingodad]

Right now I'm looking at this parser generator suite https://melt.cs.umn.edu/ that has several interesting features.