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-c library he uses is an excellent one, it's a fully spec compliant C parser that's well maintained. I've based my C compiler on it and I haven't encountered any C code it couldn't parse yet. One time I upgraded to a new OSX and Apple added some stupid thing to their headers that broke the parser and a fix was merged within days. This means it takes away the entire headache of parsing C leaving just the actual compiling.
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<stdio.h>". 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.
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.
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".
I was curious about how this worked so I looked into the source a little (even though Haskell isn't exactly my cup of tea), and WOW... This is just amazing. The most important part of the source is highly educative literate haskell:
Sorry, I am not understanding what you're implying here. I am well aware of the definition of literate programming. (And what you've said isn't actually enough to be considered literate programming under Knuth's definition: that's just tangle, still missing weave. Though notably, a lot of people argue that weave isn't needed with today's programming languages...)
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.)
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.
As someone who knows zero haskell, and little markdown, can someone explain how this works?
haskell.org [1] says there is "bird style" and "LaTeX style" ways of marking off code vs documentation, and I see neither in the linked file. Is it the "```haskell" blocks?
Just some additional info, because literate markdown support is not completly frictionless yet:
To so this yourself you need to add the --markdown-unlit flag to ghc and add the package "markdown-unlit" to your dependencies.
Additionally you have to symlink your .md file to .lhs, as ghc does not look at .md files (even with the --markdown-unlit flag, which I find kinda sad)
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 fixes to those mistakes.
In theory I'm a big supporter of Rust. I strongly feel that we should be using stronger-typed languages than C for developing security-critical applications, and from the outside, it looks like Rust solves a lot of my criticisms of C without giving up any benefits of C. A transition over to Rust could be a big win for security and reliability of many systems.
However, I'm reluctant to devote time to learning Rust primarily because it's not supported by GCC (or any other GPL compiler that I know of). I hope the next cool thing that that the Rust community does is to continue the work done by Philip Herron[1] on a Rust front-end for GCC. I know the classic response to this is, "Do it yourself!" but there are too many other areas of Open Source that are higher priorities for me, so sadly this will have to be done by someone else if it happens at all.
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.
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.
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 an ecosystem are written in the language in said ecosystem you get a lot more (and meaningful) contributions.
Best examples: rake (and everything in the ruby ecosystem basically), the amount of people touching ruby c code is very small compared to all the 'standard tools', or cargo.
Haskell is very good at writing correct parsers easily—that's one thing. This is part of the reason it was chosen as an early perl6 test bed via pugs. Rust is getting there (I'm a big fan of the lalrpop library) but the ecosystem is no where near as mature as Haskell's for feature-complete libraries. The pace of development of the rust ecosystem is mind-boggling, though—I never guessed that rust would have taken off in popularity as much as it has.
> 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)
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)
> Because the project is still in its early phases, it is not yet
> possible to translate most real C programs or libraries.
It is currently trying to port over semantics exactly, so the Rust code is far from idiomatic Rust. Doesn't mean it's not useful, just saying that it's trying to be 1:1.
I guess the next stage would involve translating common non-idiomatic patterns into idiomatic Rust. Looks like this could be a job for a community-managed database!
This is best handled on a per-project or per-organization basis. I would have such a project concentrate on the tooling for maintaining and developing such databases.
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 silly things in this tool's output but or certainly could be extended to do that.
It tells you about places where you can improve your code. Possible pitfalls, style issues, documentation issues, unidiomatic code, everything.
Its a developer tool so you can use rustup to switch to nightly to run clippy (and use stable otherwise) and not impose nightly on the rest of the people who use the project. We have plans for making clippy a tool that you can fetch via rustup without requiring nightly.
They're different types. isize is ssize_t (well, intptr_t), in that it is tied to the size of the address space, while C's int is not constrained. In fact, it is usually 32 bits, even on 64-bit architectures, where isize is 64 bits.
Wow. So I did some sleuthing and apparently in Rust the maximum size of an object must fit in isize, not usize. That means on 32-bit architectures you can't have arrays larger than 2GB, whereas on Linux and similar systems 32-bit processes have access to 3GBs and even the full 4GBs of address space. It actually matters for things like mmap'ing files.
Technically, C's int is constrained. C defines a minimum range of values for all the datatypes. The minimum range for int is -32767 to +32767. long is -2147483647 to +2147483647. Though the discerning pendant will claim, ex post, to target something like POSIX (which increases the bound on int, defines char as 8 bits, etc) if you point out improper use of int.
One irony of criticisms against C is that people argue it's too low level, but that's often because people treat it as too low-level. For example, novice C programmers think of C integer types in terms of bit representations and infer value ranges. Good C programmers think of C integer types in terms of representable values, understand that bit representation (specifically, hardware representation) is almost always irrelevant, and understand how to leverage the unspecified upper bounds on value ranges to improve the longevity and portability of their software.
Languages which emphasize fixed-width integers are, in some sense, a retrogression. The real problem with C integer types is you won't see the folly in poor assumptions until it's too late. Languages like Ada addressed this with explicit ranges. But I guess that was too burdensome. Fixed-width integers is an appeasement of lazy programming. I admit to being lazy and using fixed-width integers in C more than I should, but at least I feel dirty about it.
Many of the compromises Rust makes are clearly informed by the _particular_ experiences of the core team. For example, the fact that most Rust developers are of the belief that malloc failure is not recoverable (a big hold-up in adding catch_unwind) is a reflection of their experience with large desktop software. Desktop software has very complex, interdependent, and less fine-grained transaction-oriented state. Recovering from malloc failure is very hard and of little benefit. Most server software, by contrast, has more natural and consistent transactional characteristics. Logical tasks have less interdependent state, so it's both easier and more beneficial to be able to recover from malloc failure.
I think some of the choices wrt integer types is similarly informed.
> the fact that most Rust developers are of the belief that malloc failure is not recoverable
This is untrue. The true statement is similar, but has different implications -- malloc failure is usually not recoverable, and nonrecoverable malloc failure should be the default, for the problem space Rust targets (which encompasses more than low-level things). You can recover from malloc in Rust, it just requires some extra work.
No, most real-world C code will expect a C `int` to be 32 bits, while `isize` is often 64 bits.
On the other hand, at least for Unix systems `long` is often equivalent to Rust's `isize`: 32 bits for 32-bit architectures, and 64 bits for 64-bit architectures, so it would make sense to convert `long` to `isize`.
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 design goals [1]: "Corrode aims to produce Rust source code which behaves exactly the same way that the original C source behaved, if the input is free of undefined and implementation-defined behavior. ... If a programmer went to the trouble to put something in, I want it in the translated output; if it's not necessary, we can let the Rust compiler warn about it." (Edit2: cleaned up and numbered)
> 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.
I think that keeping an exact one-to-one mapping makes this tool a lot more useful. There's no telling what code depends on C idioms that would be broken by using a Rust idiom instead. Generating 100% equivalent code means that programmers can make intelligent decisions about when to switch over to Rust idioms as they continue developing the program.
Yeah, once you've got equivalent Rust, the rest is just optimization that should probably be implemented in the Rust compiler. No reason to put that stuff in the niche transpiler.
It transliterates C to Rust all right, but the Rust isn't any safer than the C that goes in. Note the representation of an null-terminated string - it's an unsafe pointer to a byte. That's what it was in C, transliterated unsafely to Rust. Some safe Rust representation for C arrays is needed.
From the description of how it translates a FOR loop, it does so by compiling it down to the primitive operations and tests. A Rust FOR loop does not emerge. That needs idiom recognition for the common cases including, at least, "for (i=0; i<n; i++) {...}".
This is a big job, but it's good someone started on it.
A Rust module that exactly captures the semantics of a C source file is a Rust module that doesn't look very much like Rust. ;-) I would like to build a companion tool which rewrites parts of a valid Rust program in ways that have the same result but make use of Rust idioms. I think it should be separate from this tool because I expect it to be useful for other folks, not just users of Corrode. I propose to call that program "idiomatic", and I think it should be written in Rust using the Rust AST from syntex_syntax.
Has anyone tried it on some real-world codebases? How about kernel code? It would be very exciting to improve real-world crash safety and security by e.g. converting popular drivers quickly and automatically, followed by a manual pass applying safer Rust semantics.
> Partial automation for migrating legacy code that was implemented in C. (This tool does not fully automate the job because its output is only as safe as the input was; you should clean up the output afterward to use Rust features and idioms where appropriate.)
This was my immediate concern. Is there any chance this tool can produce anything close to clean, safe, idiomatic, rust code?
> Is there any chance this tool can produce anything close to clean, safe, idiomatic, rust code?
That is generally not possible, unless the C code only uses specific patterns known by the converter tool. That's very unlikely, considering that people write C code to be 'quick' and usually use all kinds of tricks.
I wonder if there would be any point in using this to fuzz the Rust compiler.
On the one hand, you could use CSmith with a C compiler as a convenient oracle, but on the other you would only be covering a very limited subset of e.g. the type system.
Ah very true. I interpret it as (from Googles define) "destroy or weaken (something) gradually." i.e. destroy/weaken the C code into Rust... Maybe it's just me, though.
Only if you are talking about iron corrosion. If you own an aluminum Macbook, for instance, it was oxidized (or corroded) during manufacturing, on purpose. This protects the metal from further corrosion.
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.
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 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 statistical significant sense.
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.
I was going to downvote you for a snarky response (I felt the reply explaining that Rust also has iron/oxidation references was a better response)...
... but that's a really good link that you provided. I've never read that before & it's a great resource for thinking about how to behave socially as a programmer. While I don't agree with all of it, I love their "don't pile-on" and "don't bring negativity from outside" approach. (Plus I'm guilty of the 'feigning surprise' rule.)
If you're honestly surprised (and can't/don't hide it), the effect on the other person may be similar, but that's the nature of communication. Feigning surprise is manufacturing a situation with negative aspects.
I think the effect is the same. But that's also why I liked the link - I'm sometimes honestly surprised, or seeking clarification (eg "So you really haven't heard of the Playstation 4.5 & Playstation VR? But I thought you were a PS4 gamer?"). But by expressing it as feigning surprise, I understand that the other person feels I'm belittling or mocking them, even if that wasn't my intent.
> I was going to downvote you for a snarky response (I felt the reply explaining that Rust also has iron/oxidation references was a better response)...
100% of English speakers who hear the word "rust" will first think of metal oxidation. "Correcting" people who make that "mistake" adds nothing of value to the conversation and just expresses "I know more than you" because you know some obscure minutia that was mentioned in an IRC channel once. Nerds love doing this "I'm smarter than you" kind of shit, so much so that it is developing its own noun, "well actually". It's obnoxious and distracting and contributes nothing, so I called it out.
This is of itself a misunderstanding of the origin: that's one of many reasons it's called Rust, not the only one. There's no single reason for the name.
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.
I've used ANTLR in anger a few times and for some reason it's always left a bad taste in my mouth. I always seem to spend more time debugging how ANTLR works rather than doing the work I set out to do.
Granted most of my use cases was building a simple DSL so it might be different when talking about whole source conversion.
The documentation is really spare, but coincidentally, the books written by Terrence Parr are good reads and with the right time investment, make dealing with Antlr feel less like voodoo and more like software engineering.
> 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.
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-c library he uses is an excellent one, it's a fully spec compliant C parser that's well maintained. I've based my C compiler on it and I haven't encountered any C code it couldn't parse yet. One time I upgraded to a new OSX and Apple added some stupid thing to their headers that broke the parser and a fix was merged within days. This means it takes away the entire headache of parsing C leaving just the actual compiling.
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 would like to know, too.
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<stdio.h>". 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.
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.
Blocks, maybe? Not standardized but it's cross platform and compiler.
It's not that bad to read. The documentation alone makes it easy to work on. This was dropped in the /r/rust thread: http://jamey.thesharps.us/2016/07/translating-c-to-rust-and-...
He lays it out fairly well for people to help out.
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".
I was curious about how this worked so I looked into the source a little (even though Haskell isn't exactly my cup of tea), and WOW... This is just amazing. The most important part of the source is highly educative literate haskell:
https://github.com/jameysharp/corrode/blob/master/src/Langua...
That's an incredibly brilliant idea, there's some serious craftsmanship going on in that source file.
Kinda taking Rust's doc unit tests format to a whole new level.
Rust should have a literate source format - with how much the community focuses on documentation, this would be an excellent addition.
https://github.com/rust-lang/rust/issues/26097
With the literate style, code is prefixed and comments are raw. So, instead of:
It's
You could probably hack something together with a build.rs and a preprocessor, but that would probably not be very nice long term.
Sorry, I am not understanding what you're implying here. I am well aware of the definition of literate programming. (And what you've said isn't actually enough to be considered literate programming under Knuth's definition: that's just tangle, still missing weave. Though notably, a lot of people argue that weave isn't needed with today's programming languages...)
I mentioned it because I didn't see it in my scanning of the issue you linked to.
Edit: I should have looked more closely, sorry.
Ah, no worries! I agree the issue is slightly down in the weeds, but don't worry, it's tracking the right thing :)
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.)
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.
There'a crate for that ;) https://github.com/pnkfelix/tango
As someone who knows zero haskell, and little markdown, can someone explain how this works?
haskell.org [1] says there is "bird style" and "LaTeX style" ways of marking off code vs documentation, and I see neither in the linked file. Is it the "```haskell" blocks?
[1] https://wiki.haskell.org/Literate_programming#Haskell_and_li...
Yes, that seems to be the syntax used by literate markdown https://ghc.haskell.org/trac/ghc/wiki/LiterateMarkdown
Just some additional info, because literate markdown support is not completly frictionless yet:
To so this yourself you need to add the --markdown-unlit flag to ghc and add the package "markdown-unlit" to your dependencies. Additionally you have to symlink your .md file to .lhs, as ghc does not look at .md files (even with the --markdown-unlit flag, which I find kinda sad)
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 fixes to those mistakes.
In theory I'm a big supporter of Rust. I strongly feel that we should be using stronger-typed languages than C for developing security-critical applications, and from the outside, it looks like Rust solves a lot of my criticisms of C without giving up any benefits of C. A transition over to Rust could be a big win for security and reliability of many systems.
However, I'm reluctant to devote time to learning Rust primarily because it's not supported by GCC (or any other GPL compiler that I know of). I hope the next cool thing that that the Rust community does is to continue the work done by Philip Herron[1] on a Rust front-end for GCC. I know the classic response to this is, "Do it yourself!" but there are too many other areas of Open Source that are higher priorities for me, so sadly this will have to be done by someone else if it happens at all.
[1] https://github.com/redbrain/gccrs
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.
I also would love to see a gcc front-end for rust, but my reasons are not related to the license.
I have to support platforms that gcc has backend for, but LLVM does not.
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.
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 an ecosystem are written in the language in said ecosystem you get a lot more (and meaningful) contributions.
Best examples: rake (and everything in the ruby ecosystem basically), the amount of people touching ruby c code is very small compared to all the 'standard tools', or cargo.
Haskell is very good at writing correct parsers easily—that's one thing. This is part of the reason it was chosen as an early perl6 test bed via pugs. Rust is getting there (I'm a big fan of the lalrpop library) but the ecosystem is no where near as mature as Haskell's for feature-complete libraries. The pace of development of the rust ecosystem is mind-boggling, though—I never guessed that rust would have taken off in popularity as much as it has.
If you like lalrpop, check out nom:
https://github.com/Geal/nom
> 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
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)
might be easier to do something between clang and the llvm.
Thea author wanted me to drop a link to his blog post on contributing: http://jamey.thesharps.us/2016/07/translating-c-to-rust-and-...
as many "transpilers" / compilers, whatever you might name them, it lacks example input output.
I want to see how my new rust code base looks light, does it compile with some heuritics, or just 1:1 C to rust primitives?
It is currently trying to port over semantics exactly, so the Rust code is far from idiomatic Rust. Doesn't mean it's not useful, just saying that it's trying to be 1:1.
I guess the next stage would involve translating common non-idiomatic patterns into idiomatic Rust. Looks like this could be a job for a community-managed database!
This is best handled on a per-project or per-organization basis. I would have such a project concentrate on the tooling for maintaining and developing such databases.
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 silly things in this tool's output but or certainly could be extended to do that.
I haven't used nightly much, what all does Clippy do?
It tells you about places where you can improve your code. Possible pitfalls, style issues, documentation issues, unidiomatic code, everything.
Its a developer tool so you can use rustup to switch to nightly to run clippy (and use stable otherwise) and not impose nightly on the rest of the people who use the project. We have plans for making clippy a tool that you can fetch via rustup without requiring nightly.
Check out Clippy online! Go do http://play.integer32.com/, paste in your code, click "Clippy".
It's a linter.
Here you go. It didn't like my stdio.h. Apparently enums and unions aren't supported, but:
Was turned into:
edit: Also worth noting, it removes all comments. I believe this to be a limitation of language-c [1]
[1] https://hackage.haskell.org/package/language-c
Shouldn't a C `int` be converted to Rust's `isize`. I think that captures the spirit better.
I'm in no way connected to the project. Perhaps you should file an issue.
They're different types. isize is ssize_t (well, intptr_t), in that it is tied to the size of the address space, while C's int is not constrained. In fact, it is usually 32 bits, even on 64-bit architectures, where isize is 64 bits.
Wow. So I did some sleuthing and apparently in Rust the maximum size of an object must fit in isize, not usize. That means on 32-bit architectures you can't have arrays larger than 2GB, whereas on Linux and similar systems 32-bit processes have access to 3GBs and even the full 4GBs of address space. It actually matters for things like mmap'ing files.
Technically, C's int is constrained. C defines a minimum range of values for all the datatypes. The minimum range for int is -32767 to +32767. long is -2147483647 to +2147483647. Though the discerning pendant will claim, ex post, to target something like POSIX (which increases the bound on int, defines char as 8 bits, etc) if you point out improper use of int.
One irony of criticisms against C is that people argue it's too low level, but that's often because people treat it as too low-level. For example, novice C programmers think of C integer types in terms of bit representations and infer value ranges. Good C programmers think of C integer types in terms of representable values, understand that bit representation (specifically, hardware representation) is almost always irrelevant, and understand how to leverage the unspecified upper bounds on value ranges to improve the longevity and portability of their software.
Languages which emphasize fixed-width integers are, in some sense, a retrogression. The real problem with C integer types is you won't see the folly in poor assumptions until it's too late. Languages like Ada addressed this with explicit ranges. But I guess that was too burdensome. Fixed-width integers is an appeasement of lazy programming. I admit to being lazy and using fixed-width integers in C more than I should, but at least I feel dirty about it.
Many of the compromises Rust makes are clearly informed by the _particular_ experiences of the core team. For example, the fact that most Rust developers are of the belief that malloc failure is not recoverable (a big hold-up in adding catch_unwind) is a reflection of their experience with large desktop software. Desktop software has very complex, interdependent, and less fine-grained transaction-oriented state. Recovering from malloc failure is very hard and of little benefit. Most server software, by contrast, has more natural and consistent transactional characteristics. Logical tasks have less interdependent state, so it's both easier and more beneficial to be able to recover from malloc failure.
I think some of the choices wrt integer types is similarly informed.
> the fact that most Rust developers are of the belief that malloc failure is not recoverable
This is untrue. The true statement is similar, but has different implications -- malloc failure is usually not recoverable, and nonrecoverable malloc failure should be the default, for the problem space Rust targets (which encompasses more than low-level things). You can recover from malloc in Rust, it just requires some extra work.
On some architecture int is 32bit while isize is actually 64bit so no, that translation is definitely not the ideal one.
No, most real-world C code will expect a C `int` to be 32 bits, while `isize` is often 64 bits.
On the other hand, at least for Unix systems `long` is often equivalent to Rust's `isize`: 32 bits for 32-bit architectures, and 64 bits for 64-bit architectures, so it would make sense to convert `long` to `isize`.
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 design goals [1]: "Corrode aims to produce Rust source code which behaves exactly the same way that the original C source behaved, if the input is free of undefined and implementation-defined behavior. ... If a programmer went to the trouble to put something in, I want it in the translated output; if it's not necessary, we can let the Rust compiler warn about it." (Edit2: cleaned up and numbered)
[1] https://github.com/jameysharp/corrode#design-principles
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
> 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.
I think that keeping an exact one-to-one mapping makes this tool a lot more useful. There's no telling what code depends on C idioms that would be broken by using a Rust idiom instead. Generating 100% equivalent code means that programmers can make intelligent decisions about when to switch over to Rust idioms as they continue developing the program.
Yeah, once you've got equivalent Rust, the rest is just optimization that should probably be implemented in the Rust compiler. No reason to put that stuff in the niche transpiler.
Only for ILP64 ABIs, which aren't common.
It transliterates C to Rust all right, but the Rust isn't any safer than the C that goes in. Note the representation of an null-terminated string - it's an unsafe pointer to a byte. That's what it was in C, transliterated unsafely to Rust. Some safe Rust representation for C arrays is needed.
From the description of how it translates a FOR loop, it does so by compiling it down to the primitive operations and tests. A Rust FOR loop does not emerge. That needs idiom recognition for the common cases including, at least, "for (i=0; i<n; i++) {...}".
This is a big job, but it's good someone started on it.
couldn't that be a more general 2nd pass. rust -> rust?
This is explained in the readme:
A Rust module that exactly captures the semantics of a C source file is a Rust module that doesn't look very much like Rust. ;-) I would like to build a companion tool which rewrites parts of a valid Rust program in ways that have the same result but make use of Rust idioms. I think it should be separate from this tool because I expect it to be useful for other folks, not just users of Corrode. I propose to call that program "idiomatic", and I think it should be written in Rust using the Rust AST from syntex_syntax.
Missed the chance to name it "Crust."
There are already several projects called crust, including https://crates.io/crates/crust
Well then it could be `CRusHT` - C to Rust Haskell Translator
Has anyone tried it on some real-world codebases? How about kernel code? It would be very exciting to improve real-world crash safety and security by e.g. converting popular drivers quickly and automatically, followed by a manual pass applying safer Rust semantics.
Trying to get to computer to do exactly this.
The README explicitly states that this is far too early for real programs. It doesn't come close to supporting all of C yet.
Time to start sending PRs [1], :P
[1] https://github.com/search?utf8=%E2%9C%93&q=language%3Ac
I would hope that when this project is far enough along to feasibly do such a thing, that people don't. It's really rude.
Totally agree, it was a joke.
> Partial automation for migrating legacy code that was implemented in C. (This tool does not fully automate the job because its output is only as safe as the input was; you should clean up the output afterward to use Rust features and idioms where appropriate.)
This was my immediate concern. Is there any chance this tool can produce anything close to clean, safe, idiomatic, rust code?
> Is there any chance this tool can produce anything close to clean, safe, idiomatic, rust code?
That is generally not possible, unless the C code only uses specific patterns known by the converter tool. That's very unlikely, considering that people write C code to be 'quick' and usually use all kinds of tricks.
That's an impressive use of literate programming. By coincidence, I had just read this post by John D. Cook "Literate programming: presenting code in human order" http://www.johndcook.com/blog/2016/07/06/literate-programmin...
Here we have it gentlemen: HN bingo.
I wonder if there would be any point in using this to fuzz the Rust compiler.
On the one hand, you could use CSmith with a C compiler as a convenient oracle, but on the other you would only be covering a very limited subset of e.g. the type system.
The name "Corrode" doesn't seem very positive given the purpose of this program...
Rust is a type of corrosion.
Ah very true. I interpret it as (from Googles define) "destroy or weaken (something) gradually." i.e. destroy/weaken the C code into Rust... Maybe it's just me, though.
They probably should've used a more specific term; like "Oxidant".
Exactly, _Corrode_ makes C code _rusty_!
Ironically though the name rust is from the species of fungi https://en.m.wikipedia.org/wiki/Rust_(fungus)
I find the name creative, kind of funny and all in all very good.
I guess you could say its ironic in terms of how I think of it anyway.
> ironic
I don't even know what is and what isn't a pun anymore.
Yeah, let's not tarnish this thread any further.
Tell us how you really FEel.
It also mirrors the name "oxidation" that Mozilla uses to talk about adding rust code to firefox.
Only if you are talking about iron corrosion. If you own an aluminum Macbook, for instance, it was oxidized (or corroded) during manufacturing, on purpose. This protects the metal from further corrosion.
You could say it's what this project does.
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.
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...
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 statistical significant sense.
It's really bikeshedding.
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.
I'm not sure if that's more positive..
Carbon doesn't corrode very well.
The code has a lot of special cases. Could these be eliminated using machine translation techniques?
I understand the world play, but perhaps it's a misunderstanding of Rusts name origin ? https://www.reddit.com/r/rust/comments/27jvdt/internet_archa... It's after a fungus https://en.wikipedia.org/wiki/Rust_(fungus)
Their logo is a rust colored sprocket. Rust is full of iron/corrosion/oxidation references.
Oh great, I can't wait to hear this "well, actually"[1] for the rest of my life.
[1] https://www.recurse.com/manual#sub-sec-social-rules
I was going to downvote you for a snarky response (I felt the reply explaining that Rust also has iron/oxidation references was a better response)...
... but that's a really good link that you provided. I've never read that before & it's a great resource for thinking about how to behave socially as a programmer. While I don't agree with all of it, I love their "don't pile-on" and "don't bring negativity from outside" approach. (Plus I'm guilty of the 'feigning surprise' rule.)
+1 for the really excellent link.
Why are they talking specifically about _feigning_ surprise? Isn't the effect the same even if you're honestly surprised?
If you're honestly surprised (and can't/don't hide it), the effect on the other person may be similar, but that's the nature of communication. Feigning surprise is manufacturing a situation with negative aspects.
I think the effect is the same. But that's also why I liked the link - I'm sometimes honestly surprised, or seeking clarification (eg "So you really haven't heard of the Playstation 4.5 & Playstation VR? But I thought you were a PS4 gamer?"). But by expressing it as feigning surprise, I understand that the other person feels I'm belittling or mocking them, even if that wasn't my intent.
For me at least, it was a better explanation than XKCD 1053: https://xkcd.com/1053/
> I was going to downvote you for a snarky response (I felt the reply explaining that Rust also has iron/oxidation references was a better response)...
100% of English speakers who hear the word "rust" will first think of metal oxidation. "Correcting" people who make that "mistake" adds nothing of value to the conversation and just expresses "I know more than you" because you know some obscure minutia that was mentioned in an IRC channel once. Nerds love doing this "I'm smarter than you" kind of shit, so much so that it is developing its own noun, "well actually". It's obnoxious and distracting and contributes nothing, so I called it out.
Rust has had iron oxide puns for names for a very long time, even from people who know where Graydon got the name.
This is of itself a misunderstanding of the origin: that's one of many reasons it's called Rust, not the only one. There's no single reason for the name.
As is even stated in the parent's linked thread
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
I've used ANTLR in anger a few times and for some reason it's always left a bad taste in my mouth. I always seem to spend more time debugging how ANTLR works rather than doing the work I set out to do.
Granted most of my use cases was building a simple DSL so it might be different when talking about whole source conversion.
The documentation is really spare, but coincidentally, the books written by Terrence Parr are good reads and with the right time investment, make dealing with Antlr feel less like voodoo and more like software engineering.
I think people interested in compilers are disproportionately Haskell inclined.
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.
Haskell is very popular. It's a top 40 in a field of thousands. It's more popular than Rust.