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

[Jacob Carlborg]

On 2012-05-22 21:45, Andrew Wiley wrote:
> On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <doob at me.com
> <mailto: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.

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