Live data from Hacker News

Corrode: C to Rust translator written in Haskell

github.com

81–90 of 127 posts

Re: Corrode: C to Rust translator written in Haskell

#81

Earlier quoted context omitted.

https://github.com/rust-lang/rust/issues/26097

With the literate style, code is prefixed and comments are raw. So, instead of: -- foo is a function foo :: String -> String It's foo is a function > foo :: String -> String

Literate programming is more than that. It is encouraged to order things such that they make sense to the reader, not to the compiler. You can give names to chunks of code and later glue them all together in a different order.

My tool of choice for this is Emacs org-mode with noweb support. The source file is "tangled" (i.e. individual chunks of code are glued back together in a specified order) to create the source for the compiler to process.

Haskell itself has only limited support for literate programming. Most importantly it lacks the ability to reorder chunks of code. (noweb or org-mode babel can be used with Haskell, of course.)

Re: Corrode: C to Rust translator written in Haskell

#82
post #60
post #55

Earlier quoted context omitted.

Well, it's just building off the same (negative) connotations of "Rust", which I think was itself a questionable name, trivial though it might seem. I've been looking at newer languages recently, and I see a lot of promise in Nim -- which renamed itself from Nimrod after users warned about what it connotes. Rust could take a cue.

Well, Rust isn't actually named after iron oxide. It's actually named after the fungus ( https://en.wikipedia.org/wiki/Rust_(fungus) ). Most people just don't know about the fungus.

I'm not sure if that's more positive..

Re: Corrode: C to Rust translator written in Haskell

#83
post #74

I do get that Haskell is useful to be taken as a tool for these kind of code transformations (at least I have seen quite a few of those) but I am always a bit surprised that people would start such a project in a language that has -per se- nothing to do with either the source or the target language. I know, I know, it doesn't always have to be this way, but I am very much of the opinion that everytime good tools in a…

> I do get that Haskell is useful to be taken as a tool for these kind of code transformations (at least I have seen quite a few of those) but I am always a bit surprised that people would start such a project in a language that has -per se- nothing to do with either the source or the target language.

The author explained this in a blog post[0]: Haskell has a very complete C parser library with a nice API[1] which the author already knows, Rust doesn't; furthermore since one of the project's goal is to be as syntax-directed as possible the translator is straightforward and should be understandable with very little understanding of Haskell (which can be bootstrapped from understanding Rust)

[0] http://jamey.thesharps.us/2016/07/translating-c-to-rust-and-...

[1] http://hackage.haskell.org/package/language-c

Re: Corrode: C to Rust translator written in Haskell

#84
post #30

It's too bad this is written in Haskell. I don't have anything against Haskell, it is just not as popular a language as others.[1] Any ANTLR target language would have been a solid choice.[2] This way more of the community could contribute. This is an invaluable tool if we're truly going to see a shift from C (or C++) to Rust. [1] http://pypl.github.io/PYPL.html [2] http://www.antlr.org/download.html

The author told me that one of the reasons he chose Haskell was that there was already great tooling around working with C source code: https://hackage.haskell.org/package/language-c

In fact they have explicitly documented it: http://jamey.thesharps.us/2016/07/translating-c-to-rust-and-...

> The only reason I wrote Corrode in Haskell is because I couldn't find a complete enough C parser for Rust, and I was already familiar with the language-c parser for Haskell.

Re: Corrode: C to Rust translator written in Haskell

#85
post #63
post #35

Earlier quoted context omitted.

Shouldn't a C `int` be converted to Rust's `isize`. I think that captures the spirit better.

Not to look a gift horse in the mouth, but it seems like Corrode misses some other chances to use idiomatic Rust: 1. Rust fn:main doesn't need to return something. 2. The arguments to main aren't mutated, so Rust doesn't need to declare them as mutable. 3. Ditto for the argument to printf. Anyone know how easy it is to recognize and code for such cases in the transpiler? Edit: It looks like they might have opposite d…

> Anyone know how easy it is to recognize and code for such cases in the transpiler? Edit: It looks like they might have opposite design goals

Yes the author has explicitly noted that they want a compiler as syntax-directed as possible, semantics change would go against that grain. In that spirit, idiomatic alterations would be the domain of rust-land fixers and linters (e.g. `cargo wololo` or `cargo clippy | rustfix`)

Re: Corrode: C to Rust translator written in Haskell

#86

Earlier quoted context omitted.

On the rust subreddit someone tongue-in-cheek suggested `cargo clippy | rustfix` to be used in conjunction with this tool for better rust code. But that actually could work! Clippy has a ton of lints that make your code more idiomatic, and rustfix basically takes diagnostic output and applies suggestions (still WIP). Clippy is geared towards making human-written unidiomatic code better, so it might not catch some sil…

I haven't used nightly much, what all does Clippy do?

It's a linter.

Re: Corrode: C to Rust translator written in Haskell

#87
post #74

I do get that Haskell is useful to be taken as a tool for these kind of code transformations (at least I have seen quite a few of those) but I am always a bit surprised that people would start such a project in a language that has -per se- nothing to do with either the source or the target language. I know, I know, it doesn't always have to be this way, but I am very much of the opinion that everytime good tools in a…

> I do get that Haskell is useful to be taken as a tool for these kind of code transformations (at least I have seen quite a few of those) but I am always a bit surprised that people would start such a project in a language that has -per se- nothing to do with either the source or the target language. The author explained this in a blog post[0]: Haskell has a very complete C parser library with a nice API[1] which th…

Thanks, I had overlooked that explanation.

My -general- point still stands, appaently Haskell is very good at this and the people undertaking these projects choose to value this over ease of contribution :) (says someone who just doesn't come to terms with Haskell)

Re: Corrode: C to Rust translator written in Haskell

#88
post #61
post #60

Earlier quoted context omitted.

Well, Rust isn't actually named after iron oxide. It's actually named after the fungus ( https://en.wikipedia.org/wiki/Rust_(fungus) ). Most people just don't know about the fungus.

When it comes to connotations, "what people know about" is more important than the intent.

When it comes to connotations, the one's associated with Rust are beyond negligible...

Re: Corrode: C to Rust translator written in Haskell

#89
post #56
post #37

Absolutely blown away by the detail of the documentation. The main logic of this project is in a literate haskell file you can easily read on GitHub. https://github.com/jameysharp/corrode/blob/master/src/Langua... I wonder how readable is to someone who isn't experienced in Haskell. To me reads like a breeze, but I have a project using the exact same parsing library so maybe that puts me at an advantage. The language…

By "some stupid thing to their headers" are you referring to nullability annotations? I'm not sure what else Apple would have added to pure C headers (as opposed to obj-c) any time in the past few years.

I wanted my compiler to be able to compile a hello world. Something which would be trivial in any language, though of course not C. In C the first line of hello world is "#include". No doubt known to you, that file is a veritable quagmire of incomprehensible C constructions, specific to each operating system. So I spent a few too many nights getting my compiler to get any possible C declaration known to mankind into its symboltables, just so I could get it to the code generator phase and emit all of three or so instructions.

I forgot what the change was, and I can't find the commit that fixed it, as it seems active development on the library has resumed.

Re: Corrode: C to Rust translator written in Haskell

#90
post #63

Earlier quoted context omitted.

Not to look a gift horse in the mouth, but it seems like Corrode misses some other chances to use idiomatic Rust: 1. Rust fn:main doesn't need to return something. 2. The arguments to main aren't mutated, so Rust doesn't need to declare them as mutable. 3. Ditto for the argument to printf. Anyone know how easy it is to recognize and code for such cases in the transpiler? Edit: It looks like they might have opposite d…

> Anyone know how easy it is to recognize and code for such cases in the transpiler? Edit: It looks like they might have opposite design goals Yes the author has explicitly noted that they want a compiler as syntax-directed as possible, semantics change would go against that grain. In that spirit, idiomatic alterations would be the domain of rust-land fixers and linters (e.g. `cargo wololo` or `cargo clippy | rustfix…

So you could chain Corrode with one of those to get a C-to-idiomatic-Rust converter?

FWIW, I googled those; Clippy and rustfix just seemed to be linters that can't detect things like "you're not mutating this so drop `mut`", and I couldn't find wololo.

Post reply on HN