On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <d...@me.com> 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. > 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. > - 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. 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. - 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. 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.
