Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Corrode: C to Rust translator written in Haskell

github.com

Post reply on HN
Print view View original

121–127 of 127 posts

Re: Corrode: C to Rust translator written in Haskell

#121

Post by fractalsea »

tinco wrote: 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…

The documentation is amazing. One problem I find with rendered literate haskell is that it because quickly unclear how the indentation across blocks of code fits together. It would be nice if there was some kind of renderer that kept the indentation in the docs, or had some kind of "indentation guide".

Re: Corrode: C to Rust translator written in Haskell

#122

Post by SilasX »

coldtea wrote: post #100
SilasX wrote: post #91

Earlier quoted context omitted.

How so? For me, "rust" conjures images of a rusty nail, rust getting in your tap water, a machine in disrepair from rust, and becoming "rusty" at some skill. And I don't think I'm alone.

And Python conjures images of dangerous snakes (and people getting killed by them), Go conjures images of that argument with my SO, when she told me "go!", C# conjures images of sharp objects like knives, and PHP conjures images of programming in PHP. It's just a name, nobody really cares about rusty nails and rust in tap water when discussing Rust the programming language. And by nobody I mean nobody in the statisti…

Just so we're on the same page, are you dismissing all relevance of PL names, or just the downsides of this particular one? That is, are you saying you wouldn't balk at naming a (enterprise-promoted) language something like Filth, Feces, Pubes, Jizz, or (Brain)fuck? Would those be "just names" too?

You're right that no language's name is perfect and immune from bikeshedding; however, the psychophysical mechanism of disgust works at a far deeper, extra-rational level than other negative traits. "Rust" evokes it, pythons don't.

Re: Corrode: C to Rust translator written in Haskell

#123

Post by eridius »

axman6 wrote: post #113
eridius wrote: post #56

Earlier quoted context omitted.

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.

It was possibly even a Apple added their blocks extension to C and Obj-C, I remember this verifying some issues for Haskell tool which parsed C.

That was many years ago. I was assuming tinco was referring to something more recent. Besides, AFAIK, every usage of blocks in Apple's headers is guarded by an #if check to make sure blocks are supported, so compilers that don't support blocks won't even see them.

Re: Corrode: C to Rust translator written in Haskell

#124

Post by kerkeslager »

trajing wrote: post #112
kerkeslager wrote: post #94

This is the coolest thing I've seen on HN in a long time, and useful to boot. Hopefully this will be a very big help to people moving over to Rust from C for its safety and type-checking. In general I don't support rewrites because, as many experienced programmers have pointed out, rewrites often make many of the same mistakes as the program they're rewriting. But transpilation allows us to keep the code with all the…

I'm curious why you have an issue with the mostly-MIT licensed main Rust compiler. Could you explain?

I'm hesitant to build on a platform that could be appropriated by corporate interests. An example of this is the way Apple has appropriated BSD for MacOS. The BSD code is still open, but the tooling and funding comes from Apple to an extent which allows Apple to determine the direction to some extent.

I have no problem with MIT for smaller tools, but the compiler is too foundational a dependency to take risks on, and it needs better protections--protections which are afforded by the GPL and the FSF's funding of GNU projects.

Re: Corrode: C to Rust translator written in Haskell

#125

Post by michaelcampbell »

valarauca1 wrote: post #80
nategri wrote: post #72

This is probably the most "Hacker News" thing I've ever seen.

We won't reach peak HN until somebody writes an ARC to Node.js transpiler in Haskell.

Maybe it's me having confirmation bias, but the transpiler "market" seems to favor Haskell heavily. "...in Haskell" almost seems superfluous anymore when talking about implementations.

Re: Corrode: C to Rust translator written in Haskell

#126

Post by rekado »

fanf2 wrote: post #118
rekado wrote: post #81

Earlier quoted context omitted.

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…

There's little need to reorder Haskell code because you can define things in any order. The literate programming tangle process mainly exists to remove Pascal's order restrictions.

Reordering is still useful in Haskell. Just two examples for order dependent things in Haskell: top-level Template Haskell splicing; imports and GHC feature comments.

It can be nice to have a single document explaining the whole project, producing individual source files upon tangling. For this approach you need control over order and target files. "Literate Haskell" is hardly more than a reversal of the meaning of comments and code.

Re: Corrode: C to Rust translator written in Haskell

#127

Post by SilasX »

pshc wrote: post #65
SilasX wrote: 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…

1. A special case could be added for `main`, but it's no big deal. 2. This seems difficult as the C arguments were mutable; the algorithm would have to start doing analysis rather than direct translation. 3. Quite difficult to "know" that this printf doesn't write to its arguments, especially since the printf is manually declared.

Regarding 1., If you're still reading, it looks like they discuss what they'd have to do to move `main` to its correct Rust type:

https://github.com/jameysharp/corrode/issues/20

Post reply on HN