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
parent reply =?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
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?


 Nope. Not sure why.


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 


-- 
Денис В. Шеломовский
Denis V. Shelomovskij
May 21 2012
parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
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-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



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

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



 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.

 Andrew


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.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
May 21 2012
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 

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


 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

 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

 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 reply 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 =


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.


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
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 Andrew Wiley <wiley.andrew.j gmail.com> writes:
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

 C++? It just doesn't make any sense at all.


 I see no reason why the compiler can't be implemented in D and have a C
 interface.



Certainly possible, but we'll need to keep a bootstrap compiler around.



  What's more, building tools for D in languages other than D can be

 extremely useful. Every time a discussion for a D compiler written in D
 comes up, no one really likes to mention the benefits we've gotten from
 having a compiler written in C++:


 Again as above.


I never said a compiler couldn't be implemented in D. I said implementing
it in C++ has given us advantages that no one generally considers.



   - there are no bootstrapping problems because C++ exists on basically

 every platform D would ever want to target


 Provide a C backend.



Not if you want good codegen. Implementing it in C would disable many high
level optimizations and force a single implementation for low level
concepts that should vary across implementations. I can pull some relevant
discussions from the GCC mailing list if you're interested.

Ultimately, I think fixing what few platform-specific bugs remain on GDC is
a much better alternative. I can't speak to how well LDC does on other
platforms as I haven't touched it in a while, primarily because it doesn't
run on Windows as far as I know.

As for the argument that targeting C would be more portable, we get the
same benefit by using GCC or LLVM as a backend, so I don't really see the
improvement.

  - GDC and LDC were built without reimplementing the entire compiler

 and exist on platforms DMD doesn't support


 Just provide a C interface.



You could pull that off for LDC (although it would make bootstrapping very
difficult, as discussed), see below for GCC.


   - GDC can be formally added to GCC without the aforementioned

 reimplementation of the compiler


 That's a good point. I actually don't know what they would think about
 that.



They wouldn't accept it. Period.
The only requirement to build GCC is a working C compiler on some platform
somewhere. From there, you can bootstrap and cross compile to get to any
platform you want. They're not going to give that up.


As for the more general discussion of building a compiler-as-a-library in
D, I agree that it would be tremendously useful, but I don't think it's
quite the holy grail it first appears to be. For tools written in D, it
could be tied right in, but on any VM platform, I question whether using a
D library directly is actually feasible. Building a VM<->Native
interoperability layer is simple enough when you're just calling the
library to perform simple tasks, but we're talking about a library that
would primarily be responsible for creating and updating large data
structures (namely, the AST). Tying that into a VM language would be very
difficult to do efficiently because you'd either make a lot of VM->Native
function calls or convert the entire AST back and forth from native to
VM-land. It gets even more fun because you'd have to maintain a C-API on
the native side as well as a JNI layer (or what Mono/CLI uses) and all the
wrapper code in the VM language.
Ultimately, it may be simpler just to port the library to the language of
the actual platform. I suppose even that would probably be an improvement.
May 22 2012
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

         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 

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

 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 parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
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

        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

 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
next sibling 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

     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 parent reply "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
parent reply "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 
 […]


 It is possible to translate D to LLVM IR :) Proven by LDC.


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
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 […]


 It is possible to translate D to LLVM IR :) Proven by LDC.


 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