jake6...@gmail.com <jake6...@gmail.com>:
> On Thursday, January 3, 2019 at 5:46:39 PM UTC-5, Eric Raymond wrote:
> >
> > On Thursday, January 3, 2019 at 12:11:06 PM UTC-5, Jake Montgomery wrote:
> >>
> >> I would note that any tool that ports from C++, or even C, to Go is going
> >> to produce ugly, unmaintainable, and non-idiomatic code, at best.
> >>
> >
> > These are two different cases. I agree that graceful C++ to Go
> > transpilation is effectively impossible.
> >
> > On the other hand, I believe graceful, comment-preserving C to
> > idiomatic-Go transpilation is almost possible.
> >
>
> I might believe that it could be comment-preserving and possible graceful,
> and pretty much human readable. But I seriously doubt that it could ever
> produce anything I would call idiomatic-Go. Perhaps we have different
> definitions of that term.
Yes, we do.
> Aside from the line by line form, I also mean
> "something that an experienced go programmer might write." Idomatic-Go by
> my definition, would include the use of things like interfaces and methods.
> It uses goroutines and channels where appropriate. That is what you want if
> you want "real" go code that is usable and maintainable.
Mine is less ambitious than yours. I was implying something more like
"What a Go programmer would write if he were confined to the subset of Go
features rougly equivalent to C, plus real strings and garbage correction."
And replacing pointer walks with iteration - all that sort of thing.
Possibly a better description that "idiomatic" would be "line-by-line
translation that a Go programmer could read without wanting to barf."
And perhaps I should have said "maintainable" code rather than "idiomatic",
because my real intent was to contrast against the kind of horrifying
pseudo-assembler-like splooge that leaven and c2go generate. But I did mean
idiomatic, if in a relatively weak sense.
If this seems too weak to be interesting, remember my strategic objective.
I want to get critical infrastructure out of a memory- and type-unsafe
language that is difficult to verify in into a (more) memory- and
type-safe one in order to armor it against CVEs, basically. NTP would
be my first target but by no means my last.
Go is not perfectly memory-safe, alas, but is the first plausible
target for such a mechanized jump out of C-land that I've seen.
Perfectly idiomatic Go isn't required for this objective, just
maintainable Go that would tend to evolve into more strongly idiomatic Go as
more human hands touch it after translation.
So you understand my thinking better, here's a design sketch:
Perry Metzger, one of a relatively small number of people I consider
better qualified than me to do the job, is working on a comment and
whitespace-preserving C source-code walker that will emit
S-expressions describing an AST with some semantic annotation (types,
variable scopes, that sort of thing).
My plan is to bolt this to a rewrite engine, probably written in Lisp,
and a growing database of rewrite rules that transform the AST from
C-like to Go-like. It looks like the core language mapping won't
actually be very difficult; I expect most of the production rules will
actually be about mapping C library calls to Go library calls. Doing
a reasonably complete job of *that* is going to be a hairball, it's most
of why I'm estimating two years.
Third stage: AST goes to prettyprinter and you get Go...almost.
A crucial part of the design is that the rewrite engine will pass
through, marked "this is still C", AST spans that it can't map.
I don't expect the percentage of such spans to go entirely to zero;
the goal is, rather, to get those residuals small enough that even on
large codebases one human developer can finish off the grotty spots.
Another crucial part is that rewrite-rule development cam be
crowdsourced, and people can build their own rulebases for their
own C APIs.
I'll declare victory when I can lift the NTPsec codebase out of C with
this thing.
But this is just a plan in my head right now. I won't have time to do it
until I can leave NTPsec in a stable, reasonably finished state. And then
I'lll have to scare up funding.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
