Discussion:
Interested in being abreast of the GSoC 2012 projects? Here's how
Andrei Alexandrescu
2012-05-20 22:01:54 UTC
Permalink
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 at erdani.com
gsoc2012alex at erdani.com
gsoc2012antti-ville at 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
Jacob Carlborg
2012-05-21 06:21:57 UTC
Permalink
Post by Andrei Alexandrescu
As you may recall, we have three GSoC 2012 projects for which full-bore
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
Alex Rønne Petersen
2012-05-21 06:35:47 UTC
Permalink
Post by Jacob Carlborg
Post by Andrei Alexandrescu
As you may recall, we have three GSoC 2012 projects for which full-bore
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 R?nne Petersen
alex at lycus.org
http://lycus.org
David Nadlinger
2012-05-21 16:11:53 UTC
Permalink
On Monday, 21 May 2012 at 06:35:48 UTC, Alex R?nne Petersen
Post by Alex Rønne Petersen
Post by Jacob Carlborg
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
Antti-Ville Tuunainen
2012-05-21 13:04:00 UTC
Permalink
Post by Andrei Alexandrescu
As you may recall, we have three GSoC 2012 projects for which
As discussed in the interview and (quite badly) on the
application, I will delay the start by a week on account of
finals.
Post by Andrei Alexandrescu
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.
Denis Shelomovskij
2012-05-21 15:18:23 UTC
Permalink
Post by Andrei Alexandrescu
As you may recall, we have three GSoC 2012 projects for which full-bore
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
Andrew Wiley
2012-05-21 19:48:33 UTC
Permalink
On Mon, May 21, 2012 at 10:18 AM, Denis Shelomovskij <
Post by Andrei Alexandrescu
As you may recall, we have three GSoC 2012 projects for which full-bore
Post by Andrei Alexandrescu
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120521/feafc466/attachment.html>
Denis Shelomovskij
2012-05-22 06:42:51 UTC
Permalink
Post by Andrew Wiley
On Mon, May 21, 2012 at 10:18 AM, Denis Shelomovskij
As you may recall, we have three GSoC 2012 projects for which full-bore
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
- 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
Roman D. Boiko
2012-05-22 07:21:40 UTC
Permalink
Post by Denis Shelomovskij
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!
Jacob Carlborg
2012-05-22 08:47:01 UTC
Permalink
Post by Denis Shelomovskij
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
Jacob Carlborg
2012-05-22 08:57:07 UTC
Permalink
Post by Andrew Wiley
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.
Post by Andrew Wiley
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
Again as above.
Post by Andrew Wiley
- there are no bootstrapping problems because C++ exists on basically
every platform D would ever want to target
Provide a C backend.
Post by Andrew Wiley
- GDC and LDC were built without reimplementing the entire compiler
and exist on platforms DMD doesn't support
Just provide a C interface.
Post by Andrew Wiley
- 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.
Post by Andrew Wiley
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
Alex Rønne Petersen
2012-05-22 09:11:11 UTC
Permalink
Post by Jacob Carlborg
Post by Andrew Wiley
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.
Post by Andrew Wiley
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
Again as above.
Post by Andrew Wiley
- 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...
Post by Jacob Carlborg
Post by Andrew Wiley
- GDC and LDC were built without reimplementing the entire compiler
and exist on platforms DMD doesn't support
Just provide a C interface.
Post by Andrew Wiley
- 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.
Post by Andrew Wiley
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 at lycus.org
http://lycus.org
Jacob Carlborg
2012-05-22 10:35:13 UTC
Permalink
Post by Alex Rønne Petersen
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
Alex Rønne Petersen
2012-05-22 10:48:30 UTC
Permalink
Post by Jacob Carlborg
Post by Alex Rønne Petersen
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 at lycus.org
http://lycus.org
Jacob Carlborg
2012-05-22 10:58:58 UTC
Permalink
Post by Alex Rønne Petersen
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.
Post by Alex Rønne Petersen
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
Iain Buclaw
2012-05-22 11:31:55 UTC
Permalink
Post by Alex Rønne Petersen
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. :~)
--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jacob Carlborg
2012-05-22 12:13:05 UTC
Permalink
Post by Iain Buclaw
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
Andrew Wiley
2012-05-22 19:45:37 UTC
Permalink
Post by Andrew Wiley
Gee, thanks for your enthusiastic support for GSOC projects that will
Post by Andrew Wiley
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.
Post by Andrew Wiley
What's more, building tools for D in languages other than D can be
Post by Andrew Wiley
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
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.
Post by Andrew Wiley
- there are no bootstrapping problems because C++ exists on basically
Post by Andrew Wiley
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
Post by Andrew Wiley
Post by Andrew Wiley
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.
Post by Andrew Wiley
- GDC can be formally added to GCC without the aforementioned
Post by Andrew Wiley
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120522/b2ec17dc/attachment.html>
Jacob Carlborg
2012-05-23 06:38:53 UTC
Permalink
On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <doob at me.com
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
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
Roman D. Boiko
2012-05-23 08:46:44 UTC
Permalink
Post by Jacob Carlborg
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.
Andrew Wiley
2012-05-23 17:11:42 UTC
Permalink
On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <doob at me.com
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
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
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.
* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120523/79d7b803/attachment.html>
Jacob Carlborg
2012-05-23 19:51:45 UTC
Permalink
Post by Andrew Wiley
(Foo -> Bar means a compiler that runs on Foo and outputs binaries that
run on Bar)
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.
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.
Post by Andrew Wiley
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.
Post by Andrew Wiley
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
Roman D. Boiko
2012-05-23 21:41:34 UTC
Permalink
Post by Andrew Wiley
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.
David Nadlinger
2012-05-23 21:50:00 UTC
Permalink
Post by Roman D. Boiko
Post by Andrew Wiley
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
Roman D. Boiko
2012-05-23 22:02:13 UTC
Permalink
Post by David Nadlinger
Post by Roman D. Boiko
Post by Andrew Wiley
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.

Loading...