og2cpp
Please consider joining forces, so that we could make an amazing Og to C++17 converter:
https://github.com/xyproto/go2cpp
:+1:
That could be fun !
I greatly need some help on Og
Actually the "only" difficult thing to do is to write a new https://github.com/Champii/og/blob/master/lib/ast/ast.og that will produce the target C++ code, as well as some minor changes like an option to bypass the built-in template system (as C++ has its own)
I wonder if we could generalize the process to produce some LLVM IR code ?
Currently, I can't make Og build:
...om/champii/og% make
/bin/sh: og: command not found
=> Building from
make: og: Command not found
make: *** [Makefile:56: build] Error 127
2...om/champii/og% go build
# github.com/champii/og/parser
parser/og_parser.go:1051:32: too many arguments in call to delegate.VisitChildren
have (*SourceFileContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:1216:32: too many arguments in call to delegate.VisitChildren
have (*InterpContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:1332:32: too many arguments in call to delegate.VisitChildren
have (*PackageClauseContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:1448:32: too many arguments in call to delegate.VisitChildren
have (*ImportDeclContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:1617:32: too many arguments in call to delegate.VisitChildren
have (*ImportBodyContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:1766:32: too many arguments in call to delegate.VisitChildren
have (*ImportSpecContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:1890:32: too many arguments in call to delegate.VisitChildren
have (*ImportPathContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:2022:32: too many arguments in call to delegate.VisitChildren
have (*TopLevelDeclContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:2168:32: too many arguments in call to delegate.VisitChildren
have (*DeclarationContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:2333:32: too many arguments in call to delegate.VisitChildren
have (*ConstDeclContext, antlr.ParseTreeVisitor)
want (antlr.RuleNode)
parser/og_parser.go:2333:32: too many errors
I tried a few variations. Java is installed. Go is at version 1.11.
I'll create a new issue for this, instead.
The og2cpp transpiler now works :)
https://github.com/xyproto/ogpiler
Wow ! This is amazing !
I'm going to add a reference to it in the README very soon :)
Have you considered producing LLVM IR to generate any of the supported frontend language ? I'm actually thinking about it to make a truly generic language (that may induce a huuuuge rework but would be worth it)
Also, are you handling the full set of feature from Go ? Is it possible, thanks to your transpiler, to produce a Og compiler in C++ ? (that may need some rework tho, as the antlr4 Go runtime is not the same as the C++ one)
This open a lot of possibility, I'm also actually thinking about making a Og to Rust transpiler (Rust is so awesome)
Go2cpp needs more work on:
- chan, defer, go, interface, select, struct and type
But these should (mostly) work fine:
- break, case, const, continue, default, else, fallthrough, for, func, goto, if, import, map, package, range, return, switch and var
Ideally, I should use a more "proper" method for converting between languages, using something like https://github.com/alecthomas/participle, https://github.com/pointlander/peg or https://github.com/goccmack/gocc, but I enjoy writing things from scratch.
Go2cpp is not self-compiling yet, but it's relatively close.
Og to Rust also sounds promising!
I tried all of these parsers but i would definitely go for Antlr, as they already have grammars for all the popular languages (I based my work on their Go grammar) Even if my knowledge in grammar optimization is not well advanced (big perf problem actually on https://github.com/Champii/og/blob/master/parser/Og.g4), it is a big plus to have a reliable grammar to start with ! Also that would means that our own parsers could be kind of compatible and would ease the realization of a generic language. You should definitely give it a try :)