Why is python not written in C++ ?
in [Python]
|
From: James Mills on 3 Aug 2010 05:23 On Tue, Aug 3, 2010 at 7:04 PM, Steven D'Aprano <steve-REMOVE-THIS(a)cybersource.com.au> wrote: > True, but Nobody said it can't *readily* be implemented, not that it > can't be. So he did too :) I read that as "really" :/ --James -- -- James Mills -- -- "Problems are solved by method"
From: John Bokma on 3 Aug 2010 05:29 Carl Banks <pavlovevidence(a)gmail.com> writes: > On Aug 1, 6:09 pm, John Bokma <j...(a)castleamber.com> wrote: >> Roy Smith <r...(a)panix.com> writes: >> > In article <4c55fe82$0$9111$426a3...(a)news.free.fr>, >> > candide <cand...(a)free.invalid> wrote: >> >> >> Python is an object oriented langage (OOL). The Python main >> >> implementation is written in pure and "old" C90. Is it for historical >> >> reasons? >> >> >> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more >> >> suitable to implement an OOL with another one. >> >> > One thing that comes to mind is that it's much easier to distribute C >> > libraries than C++ libraries. >> >> In the beginning of C++ there were programs that just converted C++ to C >> (frontends). At least that is how the C++ compiler Acorn sold worked. >> So I don't think your argument was much true back then. > > No, it was that way back then too. They might all generate C code but > different C code by different backends wouldn't be able to call each > other natively. If you convert C++ to C, and compile the C code then that's not different from compiling the C code itself, correct? > For instnace the function > > int foo(int); > > might be name-mangled this way in one cfront: > > foo$d > > and this way in another: > > ____int_foo__int_i But they call both the C libraries in the same way. > The virtual table of this class: > > class Bar { > virtual int foo(int); > virtual int bar(int); > }; > > might be generated like this in one cfront: > > struct Bar$$Vtable$ { > int (*Bar$$bar$d)(int); > int (*Bar$$foo$d)(int); > }; > > and like this in another: > > struct ____class_Foo___vtable_ { > int (*foo)(int); > int (*bar)(int); > }; > > > So, just because they both generated C code, it doesn't mean they can > call one another. Why would they need to call each other? The compiled C++ code ends up as being compiled generated C code. It has been a while, but I am quite sure that the Acorn C++ front end I used could dump the actual generated C code. And this generated code should compile with a normal C compiler on a different platform. The only exception I can think of is if the front end comes with libraries you have to link against. But since this should be C as well (since there is no native C++), I don't see any problem to recreate those libraries. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: John Bokma on 3 Aug 2010 05:34 Albert Hopkins <marduk(a)letterboxes.org> writes: > But I wonder if someone has/has tried to write a programming language in > C++ and what were their experiences. The Low Level Virtual Machine (LLVM) is a compiler infrastructure, written in C++, which is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages. Originally implemented for C/C++, the language-independent design (and the success) of LLVM has since spawned a wide variety of front ends, including Objective-C, Fortran, Ada, Haskell, Java bytecode, Python, Ruby, ActionScript, GLSL, and others. http://en.wikipedia.org/wiki/LLVM Unladen Swallow is a branch of Python intended to be fully compatible and significantly faster. It uses LLVM's optimization passes and JIT compiler. http://llvm.org/ProjectsWithLLVM/#unladenswallow -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: John Bokma on 3 Aug 2010 05:38 Michael Torrie <torriem(a)gmail.com> writes: > On 08/01/2010 07:09 PM, John Bokma wrote: >>> One thing that comes to mind is that it's much easier to distribute C >>> libraries than C++ libraries. >> >> In the beginning of C++ there were programs that just converted C++ to C >> (frontends). At least that is how the C++ compiler Acorn sold worked. >> So I don't think your argument was much true back then. > > No, he is still right. Each C++ implementation did name mangling > differently leading to "C" libraries that had incompatible names and > signatures. Also each frontend could have generated incompatible > vtables and other C++ structures. So C code generated by one C++ > frontend could not easily call C code generated by another C++ frontend. > So the same arguments that are made about C++ now were just as valid > back then when C++ was merely a fancy preprocessor. See my other post: I understand that two C++ preprocessors can't call each others generated code, but if one uses C++ and knows that one can only use shared C libraries on target systems, and not C++ libraries that might be present (or more likely not: C++ was new in those days). -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: Nobody on 3 Aug 2010 05:45
On Tue, 03 Aug 2010 18:48:24 +1000, James Mills wrote: >> One feature which can't readily be implemented in C is the automatic >> clean-up side of the RAII idiom. > > C is a Turing-Complete Language is it not ? > > If so, therefore is it not true "anything" can be implemented ? > Even the "automated clean-up side of the RAIL idiom" ? By "automated", I mean the fact that destructors get called automatically when a local variable goes out of scope, whether by reaching the end of the block, return, break, continue, or an exception. In C, the clean-up has to be made explicit, i.e. not "automated". |