Interested in being abreast of the GSoC 2012 projects? Here's how

[Andrew Wiley]

On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <doob at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120522/b2ec17dc/attachment.html>