On 2012-05-21 21:48, Andrew Wiley wrote:

> Gee, thanks for your enthusiastic support for GSOC projects that will
> greatly forward the D ecosystem.
>
> Ultimately, what's useful to the D community (for reasons discussed in
> these NGs many times over) is that we have working, mature, feature-rich
> IDEs. The languages they're implemented in are mostly irrelevant, and in
> MonoDevelop's case, trying to add language support via a plugin written
> in D to an IDE written in C# would be silly. Would you extend Eclipse in
> C++? It just doesn't make any sense at all.

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

> What's more, building tools for D in languages other than D can be
> extremely useful. Every time a discussion for a D compiler written in D
> comes up, no one really likes to mention the benefits we've gotten from
> having a compiler written in C++:

Again as above.

>   - there are no bootstrapping problems because C++ exists on basically
> every platform D would ever want to target

Provide a C backend.

>   - GDC and LDC were built without reimplementing the entire compiler
> and exist on platforms DMD doesn't support

Just provide a C interface.

>   - GDC can be formally added to GCC without the aforementioned
> reimplementation of the compiler

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

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



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

I agree.

-- 
/Jacob Carlborg

On 22-05-2012 10:57, Jacob Carlborg wrote:
> On 2012-05-21 21:48, Andrew Wiley wrote:
>
>> Gee, thanks for your enthusiastic support for GSOC projects that will
>> greatly forward the D ecosystem.
>>
>> Ultimately, what's useful to the D community (for reasons discussed in
>> these NGs many times over) is that we have working, mature, feature-rich
>> IDEs. The languages they're implemented in are mostly irrelevant, and in
>> MonoDevelop's case, trying to add language support via a plugin written
>> in D to an IDE written in C# would be silly. Would you extend Eclipse in
>> C++? It just doesn't make any sense at all.
>
> I see no reason why the compiler can't be implemented in D and have a C
> interface.
>
>> What's more, building tools for D in languages other than D can be
>> extremely useful. Every time a discussion for a D compiler written in D
>> comes up, no one really likes to mention the benefits we've gotten from
>> having a compiler written in C++:
>
> Again as above.
>
>> - there are no bootstrapping problems because C++ exists on basically
>> every platform D would ever want to target
>
> Provide a C backend.

?

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

>
>> - GDC and LDC were built without reimplementing the entire compiler
>> and exist on platforms DMD doesn't support
>
> Just provide a C interface.
>
>> - GDC can be formally added to GCC without the aforementioned
>> reimplementation of the compiler
>
> That's a good point. I actually don't know what they would think about
> that.
>
>> There's no shame in building off solid technologies, even if those
>> technologies have no direct link to the D ecosystem. Building IDEs in D
>> does demonstrate that D is powerful and useful, but except for Rainer
>> Schuetze and Visual D (which actually /is/ written in D), D has not been
>> the right tool for the job for reasons that have little to do with the
>> language's actual merits.
>
>
>
>> The response at this point is generally, "Why build off
>> MonoDevelop/Eclipse/VisualStudio when you could build from scratch?" and
>> again, the question is whether building from scratch makes sense.
>> Existing frameworks exist, are very powerful, are already familiar to
>> many developers, and are generally easier to build on. There's certainly
>> nothing stopping anyone from working from scratch, but building from an
>> existing framework will get faster results and all the aforementioned
>> benefits. If the heap of abandoned incomplete IDE-from-scratch projects
>> on DSource says anything, it says that fast results are important in
>> community-driven projects.
>>
>> I, for one, look forward to seeing what Alex can build this summer. Best
>> of luck as you start your project.
>>
>> Andrew
>
> I agree.
>


-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

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

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

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

On 22 May 2012 11:58, Jacob Carlborg <doob@me.com> wrote:
> 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.
>
>

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

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

On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-05-21 21:48, Andrew Wiley wrote:
>
>  Gee, thanks for your enthusiastic support for GSOC projects that will
>> greatly forward the D ecosystem.
>>
>> Ultimately, what's useful to the D community (for reasons discussed in these NGs many times over) is that we have working, mature, feature-rich IDEs. The languages they're implemented in are mostly irrelevant, and in MonoDevelop's case, trying to add language support via a plugin written in D to an IDE written in C# would be silly. Would you extend Eclipse in C++? It just doesn't make any sense at all.
>>
>
> I see no reason why the compiler can't be implemented in D and have a C interface.


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


>  What's more, building tools for D in languages other than D can be
>> extremely useful. Every time a discussion for a D compiler written in D comes up, no one really likes to mention the benefits we've gotten from having a compiler written in C++:
>>
>
> Again as above.
>
>
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.

On 2012-05-22 21:45, Andrew Wiley wrote:
> On Tue, May 22, 2012 at 3:57 AM, Jacob Carlborg <doob@me.com
> <mailto:doob@me.com>> wrote:
>
>     On 2012-05-21 21:48, Andrew Wiley wrote:
>
>         Gee, thanks for your enthusiastic support for GSOC projects that
>         will
>         greatly forward the D ecosystem.
>
>         Ultimately, what's useful to the D community (for reasons
>         discussed in
>         these NGs many times over) is that we have working, mature,
>         feature-rich
>         IDEs. The languages they're implemented in are mostly
>         irrelevant, and in
>         MonoDevelop's case, trying to add language support via a plugin
>         written
>         in D to an IDE written in C# would be silly. Would you extend
>         Eclipse in
>         C++? It just doesn't make any sense at all.
>
>
>     I see no reason why the compiler can't be implemented in D and have
>     a C interface.
>
>
> Certainly possible, but we'll need to keep a bootstrap compiler around.

You have the same problem with C and C++. Although that's way moare easier since that's what all systems use.

>         What's more, building tools for D in languages other than D can be
>         extremely useful. Every time a discussion for a D compiler
>         written in D
>         comes up, no one really likes to mention the benefits we've
>         gotten from
>         having a compiler written in C++:
>
>
>     Again as above.
>
>
> I never said a compiler couldn't be implemented in D. I said
> implementing it in C++ has given us advantages that no one generally
> considers.

Fair enough.

>           - there are no bootstrapping problems because C++ exists on
>         basically
>         every platform D would ever want to target
>
>
>     Provide a C backend.
>
>
> Not if you want good codegen. Implementing it in C would disable many
> high level optimizations and force a single implementation for low level
> concepts that should vary across implementations. I can pull some
> relevant discussions from the GCC mailing list if you're interested.

I don't understand this. Say you want port a hypothetical D compiler, DC, from Foo to Bar. You already have DC working on Foo and you already have a working C compiler on Bar. Then you just:

1. Compile DC with DC, outputting C code, on Foo
2. Take the C code to Bar and compile DC (now the C code) on Bar
3. Take the D code to Bar and compile DC (now the D code) on Bar using DC compiled from C code

> Ultimately, I think fixing what few platform-specific bugs remain on GDC
> is a much better alternative. I can't speak to how well LDC does on
> other platforms as I haven't touched it in a while, primarily because it
> doesn't run on Windows as far as I know.
>
> As for the argument that targeting C would be more portable, we get the
> same benefit by using GCC or LLVM as a backend, so I don't really see
> the improvement.

I don't say we just should drop GDC, LDC and put all our bets on a D compiler that can output C code. I'm just say what if DMD would have had a C backend from the beginning. Things might have been easier.

>           - GDC and LDC were built without reimplementing the entire
>         compiler
>         and exist on platforms DMD doesn't support
>
>
>     Just provide a C interface.
>
>
> You could pull that off for LDC (although it would make bootstrapping
> very difficult, as discussed), see below for GCC.
>
>
>           - GDC can be formally added to GCC without the aforementioned
>         reimplementation of the compiler
>
>
>     That's a good point. I actually don't know what they would think
>     about that.
>
>
> They wouldn't accept it. Period.
> The only requirement to build GCC is a working C compiler on some
> platform somewhere. From there, you can bootstrap and cross compile to
> get to any platform you want. They're not going to give that up.

Fair enough.

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

Ok, you have a point there. So what do you suggest:

* Reinventing the wheel for every language that needs a D compiler
* Don't integrate the compiler with languages that can't directly use C
* Write and IDE using D can directly interface with the compiler library

On the other hand if you have a compiler library you can build a tool based on the library that translates D code to Java, C# or perhaps their byte code equivalents. Then you can automatically translate the compiler library to whatever language you like and integrate it with VM-based IDE's.

-- 
/Jacob Carlborg

On Wednesday, 23 May 2012 at 06:38:54 UTC, Jacob Carlborg wrote:
> On the other hand if you have a compiler library you can build a tool based on the library that translates D code to Java, C# or perhaps their byte code equivalents. Then you can automatically translate the compiler library to whatever language you like and integrate it with VM-based IDE's.

I don't think it is feasible to translate code into another language reliably. I mean, preserving behavior. Such a project seems to be too big and risky.