Agreed with Daniel. The D approach would be best. They one frontend and then dmd (frontend + proprietary backend), ldc (frontend + llvm) and gdc (frontend + gcc backends) use that. This would be the best for the Rust ecosystem, users and developers of the various compilers; there's no duplication of efforts and critically, very few compiler-specific bugs. One can reasonably assume that any code written for dmd will work with ldc and gdc.
Multiple independent compilers would require a common, detailed spec to reach any level of interoperability. That comes with its own costs and complexities and IMO I don't think they're worth it. On Tue, Dec 3, 2013 at 9:58 AM, Benjamin Striegel <[email protected]>wrote: > This is very cool! But, I agree with Daniel. If there's any way that we > can reduce the duplication of effort, we should. This is especially true > given that we don't have anything close to an accurate written > specification to help keep two implementations in sync. > > > On Tue, Dec 3, 2013 at 12:54 PM, Daniel Micay <[email protected]>wrote: > >> On Tue, Dec 3, 2013 at 12:22 PM, Philip Herron <[email protected]> >> wrote: >> > Hey all >> > >> > Some of you may have noticed the gccrs branch on the git mirror. Since >> PyCon >> > IE 2013 i gave a talk on my Python Front-end pet project and heard about >> > rust by a few people and i never really looked at it before until then >> but >> > i've kind of been hooked since. >> > >> > So to learn the language i've been writing this front-end to GCC. Only >> > really a a month or so on and off work in between work. Currently it >> > compiles alot of rust already in fairly little effort on my side GCC is >> > doing loads of the heavy lifting. >> > >> > Currently it compiles most of the basic stuff such as a struct an impl >> block >> > while loop, functions expressions calling methods passing arguments etc. >> > Currently focusing on getting the typing working correctly to support & >> and >> > ~ and look at how templates might work as well as need to implement >> break >> > and return. >> > >> > There is still a lot of work but i would really like to share it and see >> > what people think. Personally i think rust will target GCC very well >> and be >> > a good addition (if / when it works). I really want to try and give >> back to >> > this community who have been very good to me in learning over the last >> few >> > years with GSOC. >> > >> > To get a jist of what i am compiling in my tests are something like: >> > >> > fn fib1 (n:int) -> int { >> > if (n <= 1) { 1 } >> > else { n * fib1 (n - 1) } >> > } >> > >> > fn fib2 (n:int) -> int { >> > let mut i = 1; >> > let mut result = 1; >> > while (i <= n) { >> > result = result * i; >> > i = i + 1; >> > } >> > result >> > } >> > >> > fn main () { >> > fib1 (10); >> > fib2 (10); >> > } >> > >> > Or >> > >> > struct mytype { >> > x : int >> > } >> > >> > impl mytype { >> > fn test (self) -> int { >> > println ("yyoyoyo"); >> > test2 (1) >> > } >> > } >> > >> > fn main () { >> > let x = mytype { x : 1 }; >> > let z = x.x; >> > let y = x.test (); >> > let a = test2 (y); >> > } >> > >> > fn test2 (x : int) -> int { >> > let z = x; >> > 1 + z >> > } >> > >> > Theses are both pretty abstract test cases but were the ones i just made >> > work a while ago. Lots more work to do on it but i feel these 2 test >> cases >> > working is kind of a mile stone for me. >> > >> > I will start a wiki page on the project and the code i work on is at >> > http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i >> have >> > it on github first mostly for travis CI and so i can do a bunch of >> commits >> > and rebase etc http://github.com/redbrain/gccrs >> > >> > Thanks >> > >> > --Phil >> >> I think another backend would be very valuable, but not another >> implementation of the rest of the compiler. I would expect a gcc >> backend to be based on libsyntax/librustc with an alternate backend >> for `trans` and `back`. >> >> Implementing a fully compatible compiler with a full parser/macros, >> metadata, type-checking, borrow checking, liveness checking, type >> inference, privacy/reachability, etc. doesn't seem feasible. The >> upstream compiler already has hundreds of issues to fix in these >> areas. >> _______________________________________________ >> 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
