Graydon wrote (private correspondence with roc and me in late 2009): "<brendan>I'm sympathetic to the second point [roc argued for style enforcement especially to ease (semi-)automatic refactoring]. Go has gofmt and elective use of it before checkin. Refactoring is still too hard even with our impressive pork-based patch generation tools.</brendan>
As am I. I initially baked this sort of requirement into Rust but thought it would sound too pedantic so dropped it at first. Happy to revive. There are a few peculiarities of course: - Formatting trivial differences. 0xff should pretty-print back as 0xff not 15. Likewise 0xffff_ffff should not decay to 0xffffffff nor should "hel\u006c\u006co" decay to "hello". - Preservation or elision of comments. Comment <-> documentation relationship, and/or comment <-> unit test (cf. python doctests) I have no clear ideas here. At the moment Rust fe strips whitespace and comments but I'm not at all wedded to that. - Preservation of staged compilation. Rust's design has a (conservative) syntax-extension system, a bit like lisp readtables or camlp4 extensions, so these change the source text. Preserving text in a compiled artifact entails preserving multiple texts if some of them are staged output. The easiest approach I could come up with that would be practical would be (a) a gofmt-like formatting-enforcer mode on the frontend and (b) an option to simply embed a gzipped text-of-the-program in the binary output with the dwarf info pointing into it rather than into external files. Would be a small dwarf enhancement to teach gdb to use this. *shrug* or just use a symbol-server approach. -Graydon" Things have progressed since then but this still seemed fresh and I thought worth sharing -- hope it's ok to cite, wasn't really meant to be narrowcast back in the day (my fault probably). /be On Dec 9, 2011, at 8:25 AM, Niko Matsakis wrote: > We already have a pretty printer, maybe we should just make it a bit better > and run with it as the "official style"? > > On 12/9/11 7:44 AM, Dave Herman wrote: >>>> - *Compilers* that are obnoxious about dotting every i and crossing >>>> every t are a very different thing from *tools* that enforce style. >>>> Running a lint tool, or tying a lint tool to a build process, or to a >>>> check-in process -- those things all make perfect sense to me. But >>>> yelling at me for indentation when I'm trying to hack? >>> Do you really write code using arbitrary indentation and other style, >>> and then reformat it to the project style when you submit patches? >>> I've never noticed anyone doing that. On the contrary, I think I'd >>> crank code out faster if I didn't have to keep checking that I'm using >>> the correct style for the project I'm working in. >> It's just been my experience that over-strict compiler errors get in the way >> of the development process because I often need to try things out before >> they're finished. For example, back in the bootstrap compiler days, we had >> Ocaml configured to fail if there were any dead variables. This was >> incredibly frustrating and distracting. >> >> But one alternative we could consider, that would largely have the social >> effect you're looking for (enforcing a standard style and eliminating >> annoying style differences between projects) would be a tool like gofmt: >> >> http://golang.org/cmd/gofmt/ >> >> This is not part of the go compiler, but by shipping a tool with the >> language that enforces a particular style, it sends a clear message that >> this is the language's official style. And by making the tool useful, it >> provides a carrot to use that style. But it doesn't have the danger of >> interrupting the edit-compile-run workflow by nagging the user about >> syntactic nits. >> >> I believe they've also used it as a refactoring tool to help programmers >> migrate their code when the language changes, which is a useful trick, too. >> >> You could worry that some projects would still adopt their own style, but a) >> there are practical benefits to using the official language style, and b) we >> could still set cultural norms about using the official language style. In >> practice, I think there would be so much more uniformity of style that it >> would probably make non-conformists look silly and stubborn. >> >> Dave >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
