On 2012-05-22 21:45, Andrew Wiley wrote:
On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <[email protected]
<mailto:[email protected]>> wrote:
On 2012-05-21 21:48, Andrew Wiley wrote:
Gee, thanks for your enthusiastic support for GSOC projects that
will
greatly forward the D ecosystem.
Ultimately, what's useful to the D community (for reasons
discussed in
these NGs many times over) is that we have working, mature,
feature-rich
IDEs. The languages they're implemented in are mostly
irrelevant, and in
MonoDevelop's case, trying to add language support via a plugin
written
in D to an IDE written in C# would be silly. Would you extend
Eclipse in
C++? It just doesn't make any sense at all.
I see no reason why the compiler can't be implemented in D and have
a C interface.
Certainly possible, but we'll need to keep a bootstrap compiler around.
You have the same problem with C and C++. Although that's way moare
easier since that's what all systems use.
What's more, building tools for D in languages other than D can be
extremely useful. Every time a discussion for a D compiler
written in D
comes up, no one really likes to mention the benefits we've
gotten from
having a compiler written in C++:
Again as above.
I never said a compiler couldn't be implemented in D. I said
implementing it in C++ has given us advantages that no one generally
considers.
Fair enough.
- there are no bootstrapping problems because C++ exists on
basically
every platform D would ever want to target
Provide a C backend.
Not if you want good codegen. Implementing it in C would disable many
high level optimizations and force a single implementation for low level
concepts that should vary across implementations. I can pull some
relevant discussions from the GCC mailing list if you're interested.
I don't understand this. Say you want port a hypothetical D compiler,
DC, from Foo to Bar. You already have DC working on Foo and you already
have a working C compiler on Bar. Then you just:
1. Compile DC with DC, outputting C code, on Foo
2. Take the C code to Bar and compile DC (now the C code) on Bar
3. Take the D code to Bar and compile DC (now the D code) on Bar using
DC compiled from C code
Ultimately, I think fixing what few platform-specific bugs remain on GDC
is a much better alternative. I can't speak to how well LDC does on
other platforms as I haven't touched it in a while, primarily because it
doesn't run on Windows as far as I know.
As for the argument that targeting C would be more portable, we get the
same benefit by using GCC or LLVM as a backend, so I don't really see
the improvement.
I don't say we just should drop GDC, LDC and put all our bets on a D
compiler that can output C code. I'm just say what if DMD would have had
a C backend from the beginning. Things might have been easier.
- GDC and LDC were built without reimplementing the entire
compiler
and exist on platforms DMD doesn't support
Just provide a C interface.
You could pull that off for LDC (although it would make bootstrapping
very difficult, as discussed), see below for GCC.
- GDC can be formally added to GCC without the aforementioned
reimplementation of the compiler
That's a good point. I actually don't know what they would think
about that.
They wouldn't accept it. Period.
The only requirement to build GCC is a working C compiler on some
platform somewhere. From there, you can bootstrap and cross compile to
get to any platform you want. They're not going to give that up.
Fair enough.
As for the more general discussion of building a compiler-as-a-library
in D, I agree that it would be tremendously useful, but I don't think
it's quite the holy grail it first appears to be. For tools written in
D, it could be tied right in, but on any VM platform, I question whether
using a D library directly is actually feasible. Building a VM<->Native
interoperability layer is simple enough when you're just calling the
library to perform simple tasks, but we're talking about a library that
would primarily be responsible for creating and updating large data
structures (namely, the AST). Tying that into a VM language would be
very difficult to do efficiently because you'd either make a lot of
VM->Native function calls or convert the entire AST back and forth from
native to VM-land. It gets even more fun because you'd have to maintain
a C-API on the native side as well as a JNI layer (or what Mono/CLI
uses) and all the wrapper code in the VM language.
Ultimately, it may be simpler just to port the library to the language
of the actual platform. I suppose even that would probably be an
improvement.
Ok, you have a point there. So what do you suggest:
* Reinventing the wheel for every language that needs a D compiler
* Don't integrate the compiler with languages that can't directly use C
* Write and IDE using D can directly interface with the compiler library
On the other hand if you have a compiler library you can build a tool
based on the library that translates D code to Java, C# or perhaps their
byte code equivalents. Then you can automatically translate the compiler
library to whatever language you like and integrate it with VM-based IDE's.
--
/Jacob Carlborg
