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
