digitalmars.D - Interested in being abreast of the GSoC 2012 projects? Here's how
- Andrei Alexandrescu (23/23) May 20 2012 As you may recall, we have three GSoC 2012 projects for which full-bore
- Jacob Carlborg (5/11) May 20 2012 I was just wondering what happened to the GSoC projects. Was this ever
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (6/16) May 20 2012 Nope. Not sure why.
- David Nadlinger (7/12) May 21 2012 Yeah, I wonder as well – in any case, the chosen projects have
- Antti-Ville Tuunainen (11/15) May 21 2012 As discussed in the interview and (quite badly) on the
- Denis Shelomovskij (6/10) May 21 2012 Yes, lets accept D failure in writing anything as complicated as IDE and...
- Andrew Wiley (40/49) May 21 2012 =D0=BB:
- Denis Shelomovskij (12/59) May 21 2012 I agree. But that isn't what I meant to say. There is no reason D
- Roman D. Boiko (5/15) May 22 2012 Implementing such Core system is the goal of my DCT project.
- Jacob Carlborg (4/12) May 22 2012 I completely agree.
- Jacob Carlborg (10/47) May 22 2012 I see no reason why the compiler can't be implemented in D and have a C
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (8/57) May 22 2012 ?
- Jacob Carlborg (4/6) May 22 2012 Of course you need to start by writing the compiler in another language.
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (10/14) May 22 2012 Yes?
- Jacob Carlborg (8/13) May 22 2012 If you a self-hosting compiler written in D with a C backend it's easier...
- Iain Buclaw (7/15) May 22 2012 That may be a good short term goal. But for the sake of positive
- Jacob Carlborg (9/11) May 22 2012 Yes, it is a short term goal. But it would make things a lot quicker and...
- Andrew Wiley (38/69) May 22 2012 I never said a compiler couldn't be implemented in D. I said implementin...
- Jacob Carlborg (25/101) May 22 2012 You have the same problem with C and C++. Although that's way moare
- Roman D. Boiko (4/9) May 23 2012 I don't think it is feasible to translate code into another
- Andrew Wiley (32/123) May 23 2012 Yes, C/C++ are ubiquitous these days.
- Jacob Carlborg (8/41) May 23 2012 I might be less of a problem when the language isn't changed that much.
- Roman D. Boiko (5/14) May 23 2012 It is possible to translate D to LLVM IR :) Proven by LDC.
- David Nadlinger (7/11) May 23 2012 You are probably aware of this, but LLVM IR isn't a »VM
- Roman D. Boiko (3/14) May 23 2012 Yes, I know that it is not a VM, but it has some of its benefits.
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
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
On 21-05-2012 08:21, Jacob Carlborg wrote:On 2012-05-21 00:01, Andrei Alexandrescu wrote:Nope. Not sure why. -- Alex Rnne Petersen alex lycus.org http://lycus.orgAs 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?
May 20 2012
On Monday, 21 May 2012 at 06:35:48 UTC, Alex Rønne Petersen wrote:On 21-05-2012 08:21, Jacob Carlborg wrote: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… ;) DavidI 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.
May 21 2012
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
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 BotheYes, lets accept D failure in writing anything as complicated as IDE and -- Денис В. Шеломовский Denis V. Shelomovskij
May 21 2012
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==D0=BB:As you may recall, we have three GSoC 2012 projects for which full-boreGee, 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 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. Andrewcoding starts tomorrow: 1. Extended Unicode Support by Dmitry Olshansky 2. Mono-D by Alex BotheYes, lets accept D failure in writing anything as complicated as IDE and
May 21 2012
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 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 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. AndrewI agree. But that isn't what I meant to say. There is no reason D 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
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 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
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 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
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 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 targetProvide a C backend.- GDC and LDC were built without reimplementing the entire compiler and exist on platforms DMD doesn't supportJust provide a C interface.- GDC can be formally added to GCC without the aforementioned reimplementation of the compilerThat'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. AndrewI agree. -- /Jacob Carlborg
May 22 2012
On 22-05-2012 10:57, Jacob Carlborg wrote:On 2012-05-21 21:48, Andrew Wiley 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...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 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 targetProvide a C backend.-- Alex Rønne Petersen alex lycus.org http://lycus.org- GDC and LDC were built without reimplementing the entire compiler and exist on platforms DMD doesn't supportJust provide a C interface.- GDC can be formally added to GCC without the aforementioned reimplementation of the compilerThat'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. AndrewI agree.
May 22 2012
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
On 22-05-2012 12:35, Jacob Carlborg wrote:On 2012-05-22 11:11, 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. Anyway, D compilers are not ubiquitous enough to justify scrapping the C++ ones yet IMO. -- Alex Rønne Petersen alex lycus.org http://lycus.orgThat 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.
May 22 2012
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
On 22 May 2012 11:58, Jacob Carlborg <doob me.com> wrote:On 2012-05-22 12:48, Alex R=F8nne Petersen wrote:toYes? 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
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
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 willCertainly possible, but we'll need to keep a bootstrap compiler around.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 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 beI 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.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 basicallyNot 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 compilerevery platform D would ever want to targetProvide a C backend.You could pull that off for LDC (although it would make bootstrapping very difficult, as discussed), see below for GCC.and exist on platforms DMD doesn't supportJust provide a C interface.- GDC can be formally added to GCC without the aforementionedThey 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.reimplementation of the compilerThat's a good point. I actually don't know what they would think about that.
May 22 2012
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 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 codeUltimately, 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 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
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 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
On Wed, May 23, 2012 at 1:38 AM, Jacob Carlborg <doob me.com> wrote:On 2012-05-22 21:45, Andrew Wiley wrote:Yes, C/C++ are ubiquitous these days. What's more, building tools for D in languages other than D can beOn 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 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.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-libraryextremely 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 onbasically 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 codeUnfortunately, 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.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 libraryOn the other hand if you have a compiler library you can build a tool 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.
May 23 2012
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 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
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
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: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). DavidI agree with Roman that automated translation to a VM language […]It is possible to translate D to LLVM IR :) Proven by LDC.
May 23 2012
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: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.On Wednesday, 23 May 2012 at 17:12:15 UTC, Andrew Wiley wrote: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). DavidI agree with Roman that automated translation to a VM language […]It is possible to translate D to LLVM IR :) Proven by LDC.
May 23 2012