<div class="gmail_quote">On Wed, May 23, 2012 at 1:38 AM, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 2012-05-22 21:45, Andrew Wiley wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <<a href="mailto:doob@me.com" target="_blank">doob@me.com</a><br></div><div>
<mailto:<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>>> wrote:<br>
<br>
On 2012-05-21 21:48, Andrew Wiley wrote:<br>
<br>
Gee, thanks for your enthusiastic support for GSOC projects that<br>
will<br>
greatly forward the D ecosystem.<br>
<br>
Ultimately, what's useful to the D community (for reasons<br>
discussed in<br>
these NGs many times over) is that we have working, mature,<br>
feature-rich<br>
IDEs. The languages they're implemented in are mostly<br>
irrelevant, and in<br>
MonoDevelop's case, trying to add language support via a plugin<br>
written<br>
in D to an IDE written in C# would be silly. Would you extend<br>
Eclipse in<br>
C++? It just doesn't make any sense at all.<br>
<br>
<br>
I see no reason why the compiler can't be implemented in D and have<br>
a C interface.<br>
<br>
<br></div><div>
Certainly possible, but we'll need to keep a bootstrap compiler around.<br>
</div></blockquote>
<br>
You have the same problem with C and C++. Although that's way moare easier since that's what all systems use.<br></blockquote><div><br></div><div>Yes, C/C++ are ubiquitous these days. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
What's more, building tools for D in languages other than D can be<br>
extremely useful. Every time a discussion for a D compiler<br>
written in D<br>
comes up, no one really likes to mention the benefits we've<br>
gotten from<br>
having a compiler written in C++:<br>
<br>
<br>
Again as above.<br>
<br>
<br></div><div>
I never said a compiler couldn't be implemented in D. I said<br>
implementing it in C++ has given us advantages that no one generally<br>
considers.<br>
</div></blockquote>
<br>
Fair enough.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
- there are no bootstrapping problems because C++ exists on<br>
basically<br>
every platform D would ever want to target<br>
<br>
<br>
Provide a C backend.<br>
<br>
<br></div><div>
Not if you want good codegen. Implementing it in C would disable many<br>
high level optimizations and force a single implementation for low level<br>
concepts that should vary across implementations. I can pull some<br>
relevant discussions from the GCC mailing list if you're interested.<br>
</div></blockquote>
<br>
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:<br>
<br>
1. Compile DC with DC, outputting C code, on Foo<br>
2. Take the C code to Bar and compile DC (now the C code) on Bar<br>
3. Take the D code to Bar and compile DC (now the D code) on Bar using DC compiled from C code</blockquote><div><br></div><div>Ultimately, it doesn't really change the number of steps required:</div><div>(Foo -> Bar means a compiler that runs on Foo and outputs binaries that run on Bar)</div>
<div><br></div><div>Standard cross compiler sequence:</div><div>1. Compile DC (Foo -> Bar) on Foo using the existing DC (Foo -> Foo)</div><div>2. Compile DC (Bar -> Bar) on Foo using the newly built DC (Foo -> Bar)</div>
<div>Now you have Bar -> Bar, which is what you wanted, and we had to build DC twice. DC also has to support codegen for both Foo and Bar.</div><div><br></div><div>What you seem to be wanting is this:</div><div>1. Compile DC ((C code) -> Bar) on Foo using the existing DC (Foo -> {Foo,C})</div>
<div>2. Use the C compiler on Bar to turn (C code) -> Bar into Bar -> Bar (but this build is slow because it used C as an intermediate form)</div><div>3. Use the slow Bar -> Bar to compile a fast Bar -> Bar</div>
<div>Again, we have Bar -> Bar after two builds of DC, but DC had to support codegen for Foo, Bar, and C.</div><div><br></div><div>Targeting C doesn't really seem to make bootstrapping like this any more efficient.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for the more general discussion of building a compiler-as-a-library<br>
in D, I agree that it would be tremendously useful, but I don't think<br>
it's quite the holy grail it first appears to be. For tools written in<br>
D, it could be tied right in, but on any VM platform, I question whether<br>
using a D library directly is actually feasible. Building a VM<->Native<br>
interoperability layer is simple enough when you're just calling the<br>
library to perform simple tasks, but we're talking about a library that<br>
would primarily be responsible for creating and updating large data<br>
structures (namely, the AST). Tying that into a VM language would be<br>
very difficult to do efficiently because you'd either make a lot of<br>
VM->Native function calls or convert the entire AST back and forth from<br>
native to VM-land. It gets even more fun because you'd have to maintain<br>
a C-API on the native side as well as a JNI layer (or what Mono/CLI<br>
uses) and all the wrapper code in the VM language.<br>
Ultimately, it may be simpler just to port the library to the language<br>
of the actual platform. I suppose even that would probably be an<br>
improvement.<br>
</blockquote>
<br></div>
Ok, you have a point there. So what do you suggest:<br>
<br>
* Reinventing the wheel for every language that needs a D compiler<br>
* Don't integrate the compiler with languages that can't directly use C<br>
* Write and IDE using D can directly interface with the compiler library<br></blockquote><div><br></div><div>Unfortunately, I don't really have a satisfying solution to this. At the moment, we're reinventing the wheel. The best alternative I see if a library like this were to exist would be to port it instead of reinventing it. Maybe using it from a VM wouldn't be as hard as I'm thinking, but it's hard to speculate.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote>
<div><br></div><div>I agree with Roman that automated translation to a VM language would probably be a difficult thing to attempt, although I think it could be doable. I don't think the effort/benefit ration is low enough. It's not often that someone needs a mechanical translation of a D library to another language.</div>
</div><br>