[bitc-dev] why the switch to c++?

[rtm443x at gmail.com]

----- Original Message ---------------

Subject: Re: [bitc-dev] why the switch to c++?
   From: Sam Rushing <sam-bitc at rushing.nightmare.com>
   Date: Tue, 10 Feb 2009 13:32:33 -0800
     To: Discussions about the BitC language <bitc-dev at coyotos.org>

>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
>bitc-dev at coyotos.org
>http://www.coyotos.org/mailman/listinfo/bitc-dev