Welcome to gd2cs.py Discussions!

[kiriri]

👋 Hi!

Feel free to leave any kind of feedback you have here.

[quentincaffeino]

Hey, awesome project idea, tho I have some concerns about regex parsing when there's official grammar: https://docs.godotengine.org/en/stable/development/file_formats/gdscript_grammar.html
Best!

[kiriri]

Thank you! I did not know that was a thing. It looks extremely useful for highlighting what's missing or misimplemented. But I don't see a way to use it directly to translate the code. Did you have something in mind?

[quentincaffeino]

Grammar is intended to parse data similar to what you do with regex. See this library for python: https://github.com/neogeny/TatSu
The main advantage over using self written regex rules:

1. You don't have to update them, you just copy grammar given by godot community and use it.
2. Less potential for making error.

[quentincaffeino]

Ok sorry, I've just noticed Note block, it might be unusable...
Any way even if it is not usable might be better to write your own grammar because compared to regex:

1. You don't have to write parser and make sure it works.
2. It's more readable and very broadly used.

[kiriri]

I've looked into this a bit and feel that you're underestimating the effort required to create even a mediocre converter this way.
Unlike the regex solution, a full language model would require ALL syntactical features to be implemented, even if they are identical between c# and gd, else the parser fails. And that is a lot of work. Have a look at this python -> js language definition.
https://github.com/avinoamr/pyscript/blob/master/python.jison
And it still requires you to manually write a parser. It's just all more structured.
I won't deny that this solution would be more elegant, and it would fix the operator precedence issue I've been struggling with, but it would absolutely take forever to implement and I'm not sure I have the time for it, when the current solution works most of the time.
I'll keep experimenting with it on the side though. It's a fascinating subject :)

[quentincaffeino]

you're underestimating the effort required to create even a mediocre converter this way.

I might be. I wrote only 1 project with grammar parsing and tons with regex, and I mean it definitely depends on the project, if parsing is not the main thing then regex is fine, but overwise I consider for myself writing regex parsers like if you are writing barebones code when there's a lib or a framework for that.

Unlike the regex solution, a full language model would require ALL syntactical features to be implemented

I'm not sure about ebnf and jison, I've worked only with PEG. In it the same way you write .* in your regex to include all, the same way with peg you could include everything under specific tree unless you are ready to process that with grammar. Which would result in a string that you could process with regex or whatever.

Have a look at this python -> js language definition.

GDScript is much less feature rich than python. Also There is a difference between grammar formats which could result in larger grammar description.

And it still requires you to manually write a parser. It's just all more structured.

There might be realisations that require you to write parsers but from my experience most of the time you pass your string to parser and get a parsed AST.

it would absolutely take forever to implement and I'm not sure I have the time for it

Ofcourse final decision is on you, hope this didn't sound like I was trying to prove you your way is the wrong way)

I'll keep experimenting with it on the side though. It's a fascinating subject :)

That's very cool!)