Why is python not written in C++ ?

[Steven D'Aprano]

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" ?

True, but Nobody said it can't *readily* be implemented, not that it
can't be.

 

[James Mills]

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

 

[John Bokma]

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]

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]

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).

 

[Nobody]

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".

 

[Paul Rubin]

One feature which can't readily be implemented in C is the automatic
clean-up side of the RAII idiom.

I once did that by having an explicit stack of finalization records
linked through the call stack. The "throw" routine would traverse the
links to call the finalizers, until it found the matching "catch" which
contained a longjmp target. It wasn't as crazy as this makes it sound.

 

[Grant Edwards]

http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html

It's funny (and sad) because it's so close to being true.

(The effect, I mean, not necissarly the intent.)

There's no computing problem so simple that it can't be solved in a
complex and obtuse manner in C++.

I know that's true of any language, but from what I've seen over the
years, it "more true" in C++.

 

[Grant Edwards]

The stuff C++ adds to C is a mix of good and bad, and it's reasonably
possible to use just the good stuff and ignore the bad.

Except nobody does.

I've never programmed in Ada but I'm intrigued by these articles:

http://adahome.com/Ammo/cpp2ada.html
http://www.adaic.org/whyada/ada-vs-c/cada_art.html

I have the impression that Ada has an undeservedly bad rap because of
its early implementations and its origins in military bureaucracy.
I'd certainly consider it as an alternative to C or C++ if I had to
write a big program in a traditional procedural language.

I've always thought Ada was a pretty nice embedded/systems languages,
but some of the initial implementations were indede horrible. The one
I used for a little while ran on VAX/VMS but didn't use the VMS
filesystem, editors, or other utilities. The Ada enviroment was a
completely closed, walled system. It kept it's "files" in some sort
of opaque database and they could only be accessed, edited, compiled,
etc. from within the Ada development enviornment (a system with
really, really awful editing and build tools). There was a way to
import/export files, but it wasn't easy. Still, the Ada-environment
tools were _so_ bad that people exported a file, edited it using some
VMS-based editor and the re-imported it whenever a change needed to be
made.

Apparently the intent was to provide the identically awful
user-torturing-experience regardless of OS.

 

[Carl Banks]

If you convert C++ to C, and compile the C code then that's not
different from compiling the C code itself, correct?






But they call both the C libraries in the same way.

Go look at the original claim, the one that you responded to. "It's
much easier to distribute C libraries than C++ libraries."

Of course they can both call C libraries. All modern C++ compilers
can too, not just cfronts. What almost no C++ compiler or C++ front
can do is call a C++ library that a different C++ compiler or C++
front generated. (Unless they export function calls with C linkage,
but that's not too helpful since the ostensible benefit of C++ is
function overloading and subclassing and such, which you can't do at
all between different compilers or fronts.)

Hence, "It's much easier to distribute C libraries than C++
libraries."


[snip rest of post that misses the point]


Carl Banks

 

[Ethan Furman]

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).

So if Python were written in C++, and an extension was written in C++,
how could the two call each other?

~Ethan~

 

[John Nagle]

One thing that comes to mind is that it's much easier to distribute C
libraries than C++ libraries.

If I compile a main program with one C compiler and you compile a
dynamically loaded library with another C compiler on the same box, the
odds are pretty good they'll interoperate without any problems.

Not for Python. Extensions have to be built with essentially the
same version of the same C compiler used for building Python. This
is a major headache.

John Nagle

 

[Paul Rubin]

There's no computing problem so simple that it can't be solved in a
complex and obtuse manner in C++.

I know that's true of any language, but from what I've seen over the
years, it "more true" in C++.

http://www.willamette.edu/~fruehr/haskell/evolution.html

 

[John Bokma]

[..]

But they call both the C libraries in the same way.

Go look at the original claim, the one that you responded to. "It's
much easier to distribute C libraries than C++ libraries."

Yup, and if I read it correctly the claim was: and that's why C++ was
not chosen. I doubt it.

Hence, "It's much easier to distribute C libraries than C++
libraries."

Yup, but still doesn't exclude C++ from being used to implement a
programming language.

And I would appreciate some respect, especially from someone who's too
lazy to do some editing before posting, thank you.

 

[John Bokma]

So if Python were written in C++, and an extension was written in C++,
how could the two call each other?

Via C.

 

[Ethan Furman]

Via C.

Huh? Presumably Python itself is not a library, and the extension may
not be a library, at some point they will have different name mangling
schemes... are you suggesting that after going through the effort if
writing all this in C++ you would then have to write a wrapper in C so
the two could talk to each other?

~Ethan~

 

[Carl Banks]

[..]

But they call both the C libraries in the same way.

Go look at the original claim, the one that you responded to.  "It's
much easier to distribute C libraries than C++ libraries."

Yup, and if I read it correctly the claim was: and that's why C++ was
not chosen. I doubt it.

I think it was. Not necessarily that GvR made a list of reasons to
choose C over C++. But the fact that C++ has almost no
interoperability between compilers except via regular C linkage is a
major cultural reason why it's avoided for programs that need
extensible APIs like Python, which is why language implementors try to
avoid it.

The availability of C++ fronts that translate to C isn't the slightest
bit relevant to this.

Yup, but still doesn't exclude C++ from being used to implement a
programming language.

Well, if you want to write a language that people can write extensions
for using something other than the same C++ compiler you used, then
your only option is to use "C" external linkage which means that
whatever OOP advantages C++ gives you aren't going to be available to
extensions.

This is true even if you use a C++ front instead of a compiler.


Carl Banks

 

[Roy Smith]

Go look at the original claim, the one that you responded to. "It's
much easier to distribute C libraries than C++ libraries."

Yup, and if I read it correctly the claim was: and that's why C++ was
not chosen. I doubt it.[/QUOTE]

I didn't intend to claim quite that much. I'm just saying it's a
consideration. I was not privy to the original design decisions.

 

[Martin v. Loewis]

Has it ever been planned to rewrite in C++ the historical implementation

(of course in an object oriented design) ?

Around the time Guido coined the term "Python 3000" (i.e. in 2000), he
also said at a few occasions that it would be written in C++. He
subsequently dropped the idea, for the reasons that people have been
discussing.

Regards,
Martin

 

[Lawrence D'Oliveiro]

I've always thought Ada was a pretty nice embedded/systems languages,
but some of the initial implementations were indede horrible.

Well, there’s GNAT, the GNU Ada implementation. Seems pretty robust and
complete, while offering backward compatibility with some of those “initial
implementationsâ€, presumably because people have so much code already
written for them.

Disclaimer: the most complicated Ada program I’ve ever written is this
<http://www.codecodex.com/wiki/Concurrent_Quicksort>. Or maybe this
<http://www.codecodex.com/wiki/Parallel_Sieve_of_Eratosthenes>.