www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interested in being abreast of the GSoC 2012 projects? Here's how

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
As you may recall, we have three GSoC 2012 projects for which full-bore 
coding starts tomorrow:

1. Extended Unicode Support by Dmitry Olshansky
2. Mono-D by Alex Bothe
3. Removing the gc lock from common allocations in D by Antti-Ville 
Tuunainen.

We have a solid staff of mentors, but the larger community could add a 
lot of value to the projects in the way of giving guidance to the 
students, providing feedback, and such. To make this easier, I created 
three mailing lists for the respective projects above:

gsoc2012dmitry erdani.com
gsoc2012alex erdani.com
gsoc2012antti-ville erdani.com

These lists will carry traffic related to student-mentors communication.

If you'd like to help these projects or simply stay current with what's 
going on, please send me email (erdani.com/index.php/contact) and I will 
subscribe you to the list(s) of interest to you.

I should add that the nature of communication on these lists is 
different from the normal newsgroup exchange. Please refrain from 
off-topic discussions, tangential debates, and generally anything that 
is not directly intended to help the students do a good job on the projects.


Thanks,

Andrei
May 20 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-21 00:01, Andrei Alexandrescu wrote:
 As you may recall, we have three GSoC 2012 projects for which full-bore
 coding starts tomorrow:

 1. Extended Unicode Support by Dmitry Olshansky
 2. Mono-D by Alex Bothe
 3. Removing the gc lock from common allocations in D by Antti-Ville
 Tuunainen.

I was just wondering what happened to the GSoC projects. Was this ever announced, that it was these projects that were chosen? -- /Jacob Carlborg
May 20 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 21-05-2012 08:21, Jacob Carlborg wrote:
 On 2012-05-21 00:01, Andrei Alexandrescu wrote:
 As you may recall, we have three GSoC 2012 projects for which full-bore
 coding starts tomorrow:

 1. Extended Unicode Support by Dmitry Olshansky
 2. Mono-D by Alex Bothe
 3. Removing the gc lock from common allocations in D by Antti-Ville
 Tuunainen.

I was just wondering what happened to the GSoC projects. Was this ever announced, that it was these projects that were chosen?

Nope. Not sure why. -- Alex Rnne Petersen alex lycus.org http://lycus.org
May 20 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 21 May 2012 at 06:35:48 UTC, Alex Rønne Petersen 
wrote:
 On 21-05-2012 08:21, Jacob Carlborg wrote:
 I was just wondering what happened to the GSoC projects. Was 
 this ever
 announced, that it was these projects that were chosen?


Yeah, I wonder as well – in any case, the chosen projects have been public on Melange (Google's GSoC platform) for ages, but I didn't want to sabotage any official announcement plan by posting the link myself… ;) David
May 21 2012
prev sibling next sibling parent "Antti-Ville Tuunainen" <avtuunainen gmail.com> writes:
On Sunday, 20 May 2012 at 22:01:55 UTC, Andrei Alexandrescu wrote:
 As you may recall, we have three GSoC 2012 projects for which 
 full-bore coding starts tomorrow:

As discussed in the interview and (quite badly) on the application, I will delay the start by a week on account of finals.
 3. Removing the gc lock from common allocations in D by 
 Antti-Ville Tuunainen.

My project turned out to be rather badly named, as due to changed circumstances, I will not work on the lock, at least not initially. Instead, David convinced me that I should try to implement the druntime side of precise marking. Lockless allocation will be implemented one the precise marking works, or when I'm totally stuck on it for long enough that I need to work on something else for a while instead.
May 21 2012
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
21.05.2012 2:01, Andrei Alexandrescu написал:
 As you may recall, we have three GSoC 2012 projects for which full-bore
 coding starts tomorrow:

 1. Extended Unicode Support by Dmitry Olshansky
 2. Mono-D by Alex Bothe

Yes, lets accept D failure in writing anything as complicated as IDE and glorify C#! -- Денис В. Шеломовский Denis V. Shelomovskij
May 21 2012
next sibling parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
--f46d040890c71f2e2104c09131af
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 21, 2012 at 10:18 AM, Denis Shelomovskij <
verylonglogin.reg gmail.com> wrote:

 21.05.2012 2:01, Andrei Alexandrescu =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=

  As you may recall, we have three GSoC 2012 projects for which full-bore
 coding starts tomorrow:

 1. Extended Unicode Support by Dmitry Olshansky
 2. Mono-D by Alex Bothe

Yes, lets accept D failure in writing anything as complicated as IDE and glorify C#!

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. 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++: - there are no bootstrapping problems because C++ exists on basically every platform D would ever want to target - GDC and LDC were built without reimplementing the entire compiler and exist on platforms DMD doesn't support - GDC can be formally added to GCC without the aforementioned reimplementation of the compiler There's no shame in building off solid technologies, even if those technologies have no direct link to the D ecosystem. Building IDEs in D does demonstrate that D is powerful and useful, but except for Rainer Schuetze and Visual D (which actually /is/ written in D), D has not been the right tool for the job for reasons that have little to do with the language's actual merits. The response at this point is generally, "Why build off MonoDevelop/Eclipse/VisualStudio when you could build from scratch?" and again, the question is whether building from scratch makes sense. Existing frameworks exist, are very powerful, are already familiar to many developers, and are generally easier to build on. There's certainly nothing stopping anyone from working from scratch, but building from an existing framework will get faster results and all the aforementioned benefits. If the heap of abandoned incomplete IDE-from-scratch projects on DSource says anything, it says that fast results are important in community-driven projects. I, for one, look forward to seeing what Alex can build this summer. Best of luck as you start your project. Andrew --f46d040890c71f2e2104c09131af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, May 21, 2012 at 10:18 AM, Denis Shelomov= skij <span dir=3D"ltr">&lt;<a href=3D"mailto:verylonglogin.reg gmail.com" t= arget=3D"_blank">verylonglogin.reg gmail.com</a>&gt;</span> wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> 21.05.2012 2:01, Andrei Alexandrescu =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB:<div><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> As you may recall, we have three GSoC 2012 projects for which full-bore<br> coding starts tomorrow:<br> <br> 1. Extended Unicode Support by Dmitry Olshansky<br> 2. Mono-D by Alex Bothe<br> </blockquote> <br></div> Yes, lets accept D failure in writing anything as complicated as IDE and gl= orify C#!<span><font color=3D"#888888"><br> <br></font></span></blockquote><div><br></div><div>Gee, thanks for your ent= husiastic support for GSOC projects that will greatly forward the D ecosyst= em.</div><div><br></div><div>Ultimately, what&#39;s useful to the D communi= ty (for reasons discussed in these NGs many times over) is that we have wor= king, mature, feature-rich IDEs. The languages they&#39;re implemented in a= re mostly irrelevant, and in MonoDevelop&#39;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&#39;t make any sense at all.= </div> <div><br></div><div>What&#39;s more, building tools for D in languages othe= r 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&#39;v= e gotten from having a compiler written in C++:</div> <div>=C2=A0- there are no bootstrapping problems because C++ exists on basi= cally every platform D would ever want to target</div><div>=C2=A0- GDC and = LDC were built without reimplementing the entire compiler and exist on plat= forms DMD doesn&#39;t support</div> <div>=C2=A0- GDC can be formally added to GCC without the aforementioned re= implementation of the compiler</div><div><br></div><div>There&#39;s no sham= e in building off solid technologies, even if those technologies have no di= rect link to the D ecosystem. Building IDEs in D does demonstrate that D is= powerful and useful, but except for Rainer Schuetze and Visual D (which ac= tually /is/ written in D), D has not been the right tool for the job for re= asons that have little to do with the language&#39;s actual merits.</div> <div><br></div><div>The response at this point is generally, &quot;Why buil= d off MonoDevelop/Eclipse/VisualStudio when you could build from scratch?&q= uot; and again, the question is whether building from scratch makes sense. = Existing frameworks exist, are very powerful, are already familiar to many = developers, and are generally easier to build on. There&#39;s certainly not= hing stopping anyone from working from scratch, but building from an existi= ng framework will get faster results and all the aforementioned benefits. I= f the heap of abandoned incomplete IDE-from-scratch projects on DSource say= s anything, it says that fast results are important in community-driven pro= jects.</div> <div><br></div><div>I, for one, look forward to seeing what Alex can build = this summer. Best of luck as you start your project.</div><div><br></div><d= iv>Andrew</div></div> --f46d040890c71f2e2104c09131af--
May 21 2012
next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
21.05.2012 23:48, Andrew Wiley написал:
 On Mon, May 21, 2012 at 10:18 AM, Denis Shelomovskij
 <verylonglogin.reg gmail.com <mailto:verylonglogin.reg gmail.com>> wrote:

     21.05.2012 2:01, Andrei Alexandrescu написал:

         As you may recall, we have three GSoC 2012 projects for which
         full-bore
         coding starts tomorrow:

         1. Extended Unicode Support by Dmitry Olshansky
         2. Mono-D by Alex Bothe


     Yes, lets accept D failure in writing anything as complicated as IDE
     and glorify C#!


 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.

 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++:
   - there are no bootstrapping problems because C++ exists on basically
 every platform D would ever want to target
   - GDC and LDC were built without reimplementing the entire compiler
 and exist on platforms DMD doesn't support
   - GDC can be formally added to GCC without the aforementioned
 reimplementation of the compiler

 There's no shame in building off solid technologies, even if those
 technologies have no direct link to the D ecosystem. Building IDEs in D
 does demonstrate that D is powerful and useful, but except for Rainer
 Schuetze and Visual D (which actually /is/ written in D), D has not been
 the right tool for the job for reasons that have little to do with the
 language's actual merits.

 The response at this point is generally, "Why build off
 MonoDevelop/Eclipse/VisualStudio when you could build from scratch?" and
 again, the question is whether building from scratch makes sense.
 Existing frameworks exist, are very powerful, are already familiar to
 many developers, and are generally easier to build on. There's certainly
 nothing stopping anyone from working from scratch, but building from an
 existing framework will get faster results and all the aforementioned
 benefits. If the heap of abandoned incomplete IDE-from-scratch projects
 on DSource says anything, it says that fast results are important in
 community-driven projects.

 I, for one, look forward to seeing what Alex can build this summer. Best
 of luck as you start your project.

 Andrew

I agree. But that isn't what I meant to say. There is no reason D Parser/Autocomplete proposal system/etc. should be written in C#. IMHO C# for MonoDevelop and Java for Eclipse should be just layers of interaction with one monolithic standard Core D-IDE system. It's completely wrong that every IDE developer creates his own Core D-IDE stuff. I dream about such Core system so Visual-D/Mono-D/DDT will have same autocompletion/refactoring/etc. and every of these proect will be thin, easy to understand/improve IDE environment abstraction layer. -- Денис В. Шеломовский Denis V. Shelomovskij
May 21 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-22 08:42, Denis Shelomovskij wrote:

 I agree. But that isn't what I meant to say. There is no reason D
 Parser/Autocomplete proposal system/etc. should be written in C#. IMHO
 C# for MonoDevelop and Java for Eclipse should be just layers of
 interaction with one monolithic standard Core D-IDE system. It's
 completely wrong that every IDE developer creates his own Core D-IDE
 stuff. I dream about such Core system so Visual-D/Mono-D/DDT will have
 same autocompletion/refactoring/etc. and every of these proect will be
 thin, easy to understand/improve IDE environment abstraction layer.

I completely agree. -- /Jacob Carlborg
May 22 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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.
 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.
   - there are no bootstrapping problems because C++ exists on basically
 every platform D would ever want to target

Provide a C backend.
   - GDC and LDC were built without reimplementing the entire compiler
 and exist on platforms DMD doesn't support

Just provide a C interface.
   - 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.
 There's no shame in building off solid technologies, even if those
 technologies have no direct link to the D ecosystem. Building IDEs in D
 does demonstrate that D is powerful and useful, but except for Rainer
 Schuetze and Visual D (which actually /is/ written in D), D has not been
 the right tool for the job for reasons that have little to do with the
 language's actual merits.

 The response at this point is generally, "Why build off
 MonoDevelop/Eclipse/VisualStudio when you could build from scratch?" and
 again, the question is whether building from scratch makes sense.
 Existing frameworks exist, are very powerful, are already familiar to
 many developers, and are generally easier to build on. There's certainly
 nothing stopping anyone from working from scratch, but building from an
 existing framework will get faster results and all the aforementioned
 benefits. If the heap of abandoned incomplete IDE-from-scratch projects
 on DSource says anything, it says that fast results are important in
 community-driven projects.

 I, for one, look forward to seeing what Alex can build this summer. Best
 of luck as you start your project.

 Andrew

I agree. -- /Jacob Carlborg
May 22 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 22-05-2012 10:57, Jacob Carlborg 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.
 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.
 - there are no bootstrapping problems because C++ exists on basically
 every platform D would ever want to target

Provide a C backend.

? That doesn't solve the bootstrapping problem. You need a D compiler to build D code. And if the D compiler is written in D...
 - GDC and LDC were built without reimplementing the entire compiler
 and exist on platforms DMD doesn't support

Just provide a C interface.
 - 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.
 There's no shame in building off solid technologies, even if those
 technologies have no direct link to the D ecosystem. Building IDEs in D
 does demonstrate that D is powerful and useful, but except for Rainer
 Schuetze and Visual D (which actually /is/ written in D), D has not been
 the right tool for the job for reasons that have little to do with the
 language's actual merits.

 The response at this point is generally, "Why build off
 MonoDevelop/Eclipse/VisualStudio when you could build from scratch?" and
 again, the question is whether building from scratch makes sense.
 Existing frameworks exist, are very powerful, are already familiar to
 many developers, and are generally easier to build on. There's certainly
 nothing stopping anyone from working from scratch, but building from an
 existing framework will get faster results and all the aforementioned
 benefits. If the heap of abandoned incomplete IDE-from-scratch projects
 on DSource says anything, it says that fast results are important in
 community-driven projects.

 I, for one, look forward to seeing what Alex can build this summer. Best
 of luck as you start your project.

 Andrew

I agree.

-- Alex Rønne Petersen alex lycus.org http://lycus.org
May 22 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-22 11:11, Alex Rønne Petersen wrote:

 That doesn't solve the bootstrapping problem. You need a D compiler to
 build D code. And if the D compiler is written in D...

Of course you need to start by writing the compiler in another language. -- /Jacob Carlborg
May 22 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 22-05-2012 12:35, Jacob Carlborg wrote:
 On 2012-05-22 11:11, Alex Rønne Petersen wrote:

 That doesn't solve the bootstrapping problem. You need a D compiler to
 build D code. And if the D compiler is written in D...

Of course you need to start by writing the compiler in another language.

Yes? But what was your point about a "C back end"? It didn't make sense in this context to me at all. Anyway, D compilers are not ubiquitous enough to justify scrapping the C++ ones yet IMO. -- Alex Rønne Petersen alex lycus.org http://lycus.org
May 22 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-22 12:48, Alex Rønne Petersen wrote:

 Yes?

 But what was your point about a "C back end"? It didn't make sense in
 this context to me at all.

If you a self-hosting compiler written in D with a C backend it's easier to port to other platforms. You just compile the D compiler with it self and output C code. Then you compile the C code on another platform.
 Anyway, D compilers are not ubiquitous enough to justify scrapping the
 C++ ones yet IMO.

I didn't say we should scrap the compilers written in C++. As I've said, write the compiler in D and provide a C interface to it. -- /Jacob Carlborg
May 22 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-22 13:31, Iain Buclaw wrote:

 That may be a good short term goal.  But for the sake of positive
 argument, would rather output to assembly code. :~)

Yes, it is a short term goal. But it would make things a lot quicker and easier when porting to new platforms. Also, since you don't know when you need to port the compiler to a new platform it could also considered by a long term goal. If the D compiler had the possibilty to output C code from the beginning it would be a lot easier to write applications for ARM today. -- /Jacob Carlborg
May 22 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-22 21:45, Andrew Wiley wrote:
 On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <doob me.com
 <mailto:doob 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
May 22 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-23 19:11, Andrew Wiley wrote:

 Ultimately, it doesn't really change the number of steps required:
 (Foo -> Bar means a compiler that runs on Foo and outputs binaries that
 run on Bar)

 Standard cross compiler sequence:
 1. Compile DC (Foo -> Bar) on Foo using the existing DC (Foo -> Foo)
 2. Compile DC (Bar -> Bar) on Foo using the newly built DC (Foo -> Bar)
 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.

 What you seem to be wanting is this:
 1. Compile DC ((C code) -> Bar) on Foo using the existing DC (Foo ->
 {Foo,C})
 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)
 3. Use the slow Bar -> Bar to compile a fast Bar -> Bar
 Again, we have Bar -> Bar after two builds of DC, but DC had to support
 codegen for Foo, Bar, and C.

 Targeting C doesn't really seem to make bootstrapping like this any more
 efficient.

Then what's the problem.
 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.

I might be less of a problem when the language isn't changed that much.
     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.


 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.

Perhaps a tool for automatically creating bindings to the compiler library. But then I don't know how efficient it would be to move the necessary data across the VM boundaries. -- /Jacob Carlborg
May 23 2012
prev sibling next sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Tuesday, 22 May 2012 at 06:43:02 UTC, Denis Shelomovskij wrote:
 I agree. But that isn't what I meant to say. There is no reason 
 D Parser/Autocomplete proposal system/etc. should be written in 
 C#. IMHO C# for MonoDevelop and Java for Eclipse should be just 
 layers of interaction with one monolithic standard Core D-IDE 
 system. It's completely wrong that every IDE developer creates 
 his own Core D-IDE stuff. I dream about such Core system so 
 Visual-D/Mono-D/DDT will have same 
 autocompletion/refactoring/etc. and every of these proect will 
 be thin, easy to understand/improve IDE environment abstraction 
 layer.

Implementing such Core system is the goal of my DCT project. But that's a huge amount of work, and it would be even longer without Mono D :) So thanks a lot to Alex for the great work!
May 22 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 22 May 2012 11:58, Jacob Carlborg <doob me.com> wrote:
 On 2012-05-22 12:48, Alex R=F8nne Petersen wrote:

 Yes?

 But what was your point about a "C back end"? It didn't make sense in
 this context to me at all.

If you a self-hosting compiler written in D with a C backend it's easier =

 port to other platforms. You just compile the D compiler with it self and
 output C code. Then you compile the C code on another platform.

That may be a good short term goal. But for the sake of positive argument, would rather output to assembly code. :~) --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
May 22 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--bcaec554d6067ec36904c0a54424
Content-Type: text/plain; charset=ISO-8859-1

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

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. --bcaec554d6067ec36904c0a54424 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg = <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob= me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-05-21 21:48, Andrew Wiley wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Gee, thanks for your enthusiastic support for GSOC projects that will<br> greatly forward the D ecosystem.<br> <br> Ultimately, what&#39;s useful to the D community (for reasons discussed in<= br> these NGs many times over) is that we have working, mature, feature-rich<br=

n<br> MonoDevelop&#39;s case, trying to add language support via a plugin written= <br> in D to an IDE written in C# would be silly. Would you extend Eclipse in<br=

</blockquote> <br></div> I see no reason why the compiler can&#39;t be implemented in D and have a C= interface.</blockquote><div><br></div><div>Certainly possible, but we&#39;= ll need to keep a bootstrap compiler around.</div><div>=A0</div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What&#39;s more, building tools for D in languages other than D can be<br> extremely useful. Every time a discussion for a D compiler written in D<br> comes up, no one really likes to mention the benefits we&#39;ve gotten from= <br> having a compiler written in C++:<br> </blockquote> <br></div> Again as above.<div class=3D"im"><br></div></blockquote><div><br></div><div=
I never said a compiler couldn&#39;t be implemented in D. I said implement=


<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =A0- there are no bootstrapping problems because C++ exists on basically<b= r> every platform D would ever want to target<br> </blockquote> <br></div> Provide a C backend.</blockquote><div><br></div><div>Not if you want good c= odegen. Implementing it in C would disable many high level optimizations an= d force a single implementation for low level concepts that should vary acr= oss implementations. I can pull some relevant discussions from the GCC mail= ing list if you&#39;re interested.</div> <div><br></div><div>Ultimately, I think fixing what few platform-specific b= ugs remain on GDC is a much better alternative. I can&#39;t speak to how we= ll LDC does on other platforms as I haven&#39;t touched it in a while, prim= arily because it doesn&#39;t run on Windows as far as I know.</div> <div><br></div><div>As for the argument that targeting C would be more port= able, we get the same benefit by using GCC or LLVM as a backend, so I don&#= 39;t really see the improvement.</div><div><br></div><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =A0- GDC and LDC were built without reimplementing the entire compiler<br> and exist on platforms DMD doesn&#39;t support<br> </blockquote> <br></div> Just provide a C interface.</blockquote><div><br></div><div>You could pull = that off for LDC (although it would make bootstrapping very difficult, as d= iscussed), see below for GCC.</div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =A0- GDC can be formally added to GCC without the aforementioned<br> reimplementation of the compiler<br> </blockquote> <br></div> That&#39;s a good point. I actually don&#39;t know what they would think ab= out that.</blockquote><div><br></div><div>They wouldn&#39;t accept it. Peri= od.</div><div>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&#39;re not going to give that up.</div> <div><br></div><div><br></div><div>As for the more general discussion of bu= ilding a compiler-as-a-library in D, I agree that it would be tremendously = useful, but I don&#39;t think it&#39;s quite the holy grail it first appear= s to be. For tools written in D, it could be tied right in, but on any VM p= latform, I question whether using a D library directly is actually feasible= . Building a VM&lt;-&gt;Native interoperability layer is simple enough when= you&#39;re just calling the library to perform simple tasks, but we&#39;re= talking about a library that would primarily be responsible for creating a= nd updating large data structures (namely, the AST). Tying that into a VM l= anguage would be very difficult to do efficiently because you&#39;d either = make a lot of VM-&gt;Native function calls or convert the entire AST back a= nd forth from native to VM-land. It gets even more fun because you&#39;d ha= ve to maintain a C-API on the native side as well as a JNI layer (or what M= ono/CLI uses) and all the wrapper code in the VM language.</div> <div>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 improveme= nt.</div></div><br> --bcaec554d6067ec36904c0a54424--
May 22 2012
prev sibling next sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Wednesday, 23 May 2012 at 06:38:54 UTC, Jacob Carlborg wrote:
 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.

I don't think it is feasible to translate code into another language reliably. I mean, preserving behavior. Such a project seems to be too big and risky.
May 23 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--bcaec5524242dd436104c0b73bc3
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 23, 2012 at 1:38 AM, Jacob Carlborg <doob me.com> wrote:

 On 2012-05-22 21:45, Andrew Wiley wrote:

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

Yes, C/C++ are ubiquitous these days. 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, it doesn't really change the number of steps required: (Foo -> Bar means a compiler that runs on Foo and outputs binaries that run on Bar) Standard cross compiler sequence: 1. Compile DC (Foo -> Bar) on Foo using the existing DC (Foo -> Foo) 2. Compile DC (Bar -> Bar) on Foo using the newly built DC (Foo -> Bar) 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. What you seem to be wanting is this: 1. Compile DC ((C code) -> Bar) on Foo using the existing DC (Foo -> {Foo,C}) 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) 3. Use the slow Bar -> Bar to compile a fast Bar -> Bar Again, we have Bar -> Bar after two builds of DC, but DC had to support codegen for Foo, Bar, and C. Targeting C doesn't really seem to make bootstrapping like this any more efficient. 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

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.
 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.

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. --bcaec5524242dd436104c0b73bc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, May 23, 2012 at 1:38 AM, Jacob Carlborg = <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob= me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D= "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=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div> On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg &lt;<a href=3D"mailto:doob = me.com" target=3D"_blank">doob me.com</a><br></div><div> &lt;mailto:<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>= &gt;&gt; wrote:<br> <br> =A0 =A0On 2012-05-21 21:48, Andrew Wiley wrote:<br> <br> =A0 =A0 =A0 =A0Gee, thanks for your enthusiastic support for GSOC projects= that<br> =A0 =A0 =A0 =A0will<br> =A0 =A0 =A0 =A0greatly forward the D ecosystem.<br> <br> =A0 =A0 =A0 =A0Ultimately, what&#39;s useful to the D community (for reaso= ns<br> =A0 =A0 =A0 =A0discussed in<br> =A0 =A0 =A0 =A0these NGs many times over) is that we have working, mature,= <br> =A0 =A0 =A0 =A0feature-rich<br> =A0 =A0 =A0 =A0IDEs. The languages they&#39;re implemented in are mostly<b= r> =A0 =A0 =A0 =A0irrelevant, and in<br> =A0 =A0 =A0 =A0MonoDevelop&#39;s case, trying to add language support via = a plugin<br> =A0 =A0 =A0 =A0written<br> =A0 =A0 =A0 =A0in D to an IDE written in C# would be silly. Would you exte= nd<br> =A0 =A0 =A0 =A0Eclipse in<br> =A0 =A0 =A0 =A0C++? It just doesn&#39;t make any sense at all.<br> <br> <br> =A0 =A0I see no reason why the compiler can&#39;t be implemented in D and = have<br> =A0 =A0a C interface.<br> <br> <br></div><div> Certainly possible, but we&#39;ll need to keep a bootstrap compiler around.= <br> </div></blockquote> <br> You have the same problem with C and C++. Although that&#39;s way moare eas= ier since that&#39;s what all systems use.<br></blockquote><div><br></div><= div>Yes, C/C++ are ubiquitous these days.=A0</div><div><br></div><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div> =A0 =A0 =A0 =A0What&#39;s more, building tools for D in languages other th= an D can be<br> =A0 =A0 =A0 =A0extremely useful. Every time a discussion for a D compiler<= br> =A0 =A0 =A0 =A0written in D<br> =A0 =A0 =A0 =A0comes up, no one really likes to mention the benefits we&#3= 9;ve<br> =A0 =A0 =A0 =A0gotten from<br> =A0 =A0 =A0 =A0having a compiler written in C++:<br> <br> <br> =A0 =A0Again as above.<br> <br> <br></div><div> I never said a compiler couldn&#39;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=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div> =A0 =A0 =A0 =A0 =A0- there are no bootstrapping problems because C++ exist= s on<br> =A0 =A0 =A0 =A0basically<br> =A0 =A0 =A0 =A0every platform D would ever want to target<br> <br> <br> =A0 =A0Provide 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=

relevant discussions from the GCC mailing list if you&#39;re interested.<br=

<br> I don&#39;t understand this. Say you want port a hypothetical D compiler, D= C, 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 c= ompiled from C code</blockquote><div><br></div><div>Ultimately, it doesn&#3= 9;t really change the number of steps required:</div><div>(Foo -&gt; Bar me= ans 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 -&gt; Bar) on Foo using the existing DC (Foo -&gt; Foo)</div><div>2= . Compile DC (Bar -&gt; Bar) on Foo using the newly built DC (Foo -&gt; Bar= )</div> <div>Now you have Bar -&gt; Bar, which is what you wanted, and we had to bu= ild DC twice. DC also has to support codegen for both Foo and Bar.</div><di= v><br></div><div>What you seem to be wanting is this:</div><div>1. Compile = DC ((C code) -&gt; Bar) on Foo using the existing DC (Foo -&gt; {Foo,C})</d= iv> <div>2. Use the C compiler on Bar to turn (C code) -&gt; Bar into Bar -&gt;= Bar (but this build is slow because it used C as an intermediate form)</di= v><div>3. Use the slow Bar -&gt; Bar to compile a fast Bar -&gt; Bar</div> <div>Again, we have Bar -&gt; Bar after two builds of DC, but DC had to sup= port codegen for Foo, Bar, and C.</div><div><br></div><div>Targeting C does= n&#39;t really seem to make bootstrapping like this any more efficient.</di= v> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #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&#39;t think<b= r> it&#39;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=

ve<br> interoperability layer is simple enough when you&#39;re just calling the<br=

<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&#39;d either make a lot of<br> VM-&gt;Native function calls or convert the entire AST back and forth from<= br> native to VM-land. It gets even more fun because you&#39;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&#39;t integrate the compiler with languages that can&#39;t directly u= se C<br> * Write and IDE using D can directly interface with the compiler library<br=
</blockquote><div><br></div><div>Unfortunately, I don&#39;t really have a =

. 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&#39;t= be as hard as I&#39;m thinking, but it&#39;s hard to speculate.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"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 co= de equivalents. Then you can automatically translate the compiler library t= o whatever language you like and integrate it with VM-based IDE&#39;s.</blo= ckquote> <div><br></div><div>I agree with Roman that automated translation to a VM l= anguage would probably be a difficult thing to attempt, although I think it= could be doable. I don&#39;t think the effort/benefit ration is low enough= . It&#39;s not often that someone needs a mechanical translation of a D lib= rary to another language.</div> </div><br> --bcaec5524242dd436104c0b73bc3--
May 23 2012
prev sibling next sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Wednesday, 23 May 2012 at 17:12:15 UTC, Andrew Wiley wrote:
 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.

It is possible to translate D to LLVM IR :) Proven by LDC. Almost... But I don't think D to Java or .NET would map well. And it would be very difficult to write such a mapping, almost impossible, IMO.
May 23 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 23 May 2012 at 21:41:37 UTC, Roman D. Boiko wrote:
 On Wednesday, 23 May 2012 at 17:12:15 UTC, Andrew Wiley wrote:
 I agree with Roman that automated translation to a VM language 
 […]


You are probably aware of this, but LLVM IR isn't a »VM language« of any kind, but rather a SSA-form immediate representation similar to what other compilers use – LLVM officially is not even an acronym for Low Level Virtual Machine (anymore). David
May 23 2012
prev sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Wednesday, 23 May 2012 at 21:50:02 UTC, David Nadlinger wrote:
 On Wednesday, 23 May 2012 at 21:41:37 UTC, Roman D. Boiko wrote:
 On Wednesday, 23 May 2012 at 17:12:15 UTC, Andrew Wiley wrote:
 I agree with Roman that automated translation to a VM 
 language […]


You are probably aware of this, but LLVM IR isn't a »VM language« of any kind, but rather a SSA-form immediate representation similar to what other compilers use – LLVM officially is not even an acronym for Low Level Virtual Machine (anymore). David

Yes, I know that it is not a VM, but it has some of its benefits. I didn't know that acronym has been abandoned.
May 23 2012