----- Original Message ---------------
Subject: Re: [bitc-dev] why the switch to c++? From: Sam Rushing <[email protected]> Date: Tue, 10 Feb 2009 13:32:33 -0800 To: Discussions about the BitC language <[email protected]> >Gergely Buday wrote: >> Jonathan Shapiro wrote: >> >> >>>> Just out of curiosity, what prompted the switch from Python to C++ for >>>> BitC? >>>> >>> At a certain point the complexity of the compiler got big enough that Python >>> was no longer the right tool. We went to C++ rather than C because we wanted >>> to use smart pointers. In hindsight, we should have stuck with C. >>> >> >> Ever considered a functional language? >> > >Well, the obvious candidate is BitC itself. Is it far enough along >(ignoring the syntax issue for the moment) to be able to do this? > >-Sam >-Sam Hi all, the obvious candidate to me is lisp. You can then get BitC-in-lisp working comfortably, then bootstrap into BitC as you suggest. I'm reading up ATM about the evolution of the language at <http://www.bitc-lang.org/docs/bitc/bitc-origins.html> and it says there " ...it became clear that the transform being performed by our macros [ACL2 macros that effectively built into BitC, as I understand it] was not a simple transform. The entire strategy for "BitC as Macros" relied on the transform being simple, because ACL2 was going to report problems using the post-transform code, and we needed to be able to see from that how to fix the original. " Could it be made a proper compilation in lisp rather than macros in lisp (or a mix)? That way you don't have to deal with C++ if it's a problem. On the C++ front, it was said somewhere that it was used because of smart pointers. IIRC (it's been a long time since I used C++, though not long enough) smart pointers are used for resource management; ref counting as pseudo garbage collection. If that's all they're used for, well, I once wrote a prototype compiler (nothing fancy) and because it wasn't for production use I made no effort to clean up any memory. It leaked heroically. And that was fine. For a prototyping/bootstrapping compiler, why not. If necessary you can track down & fix the few worst leaks, which should be both easy and also cure 80%-90% of the leakage, as low-hanging fruit tends to do IME. However there likely are other reasons why this was done beyond memory management. Disclaimer: I've read about but never used lisp in its brackety form. I did though try out dylan some years ago, which has been described as a subset of scheme. Another disclaimer: there's an awful lot of stuff around BitC which I don't know about, notation, type theory, you name it. I'll try to catch up but be prepared for some unclever questions while I find my feet. cheers jan > >_______________________________________________ >bitc-dev mailing list >[email protected] >http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
