DMD source overview?

[Nick Sabalausky]

"Denis Koroskin" <2korden at gmail.com> wrote in message 
news:op.vi1hasy7o7cclz at korden-pc...
> On Tue, 14 Sep 2010 23:33:37 +0400, Nick Sabalausky <a at a.a> wrote:
>
>> But you do raise a good point. What's the current state of ddmd's 
>> front-end?
>
> It's at 2.039 atm, and it improves rapidly, e.g. it was at 2.032 about 3 
> weeks ago.

And the front-end is completely fully-functional?

>
>> What I have in mind is to just rip out dmd's current backend stuff 
>> entirely,
>> maybe even including the toObjFile and toIR methods, or at least big 
>> chunks
>> of them, and replace it all with a PHP-generator. (Yea...I'm fairly
>> determined to be able to do as much of my web dev as possible in D.) So
>> depending on the current level of ddmd's progress, I'm wondering if it 
>> might
>> be more practical to just stick with my orignal plan of using dmd and 
>> then
>> switch over to ddmd once ddmd is ready. Although, one benefit of using 
>> dmd
>> is it would likely make it quicker and easier to merge in changes from 
>> new
>> dmd releases.
>>
>>
>
> I would recommend against heavy modification of the original code (e.g. 
> getting rid of toIR/toObjFile, be it dmd or ddmd). Use external visitors 
> if possible.
>

I was deciding between modifying parts of toIR/toObjFile versus just 
side-stepping them entirely and traversing the tree externally.  I guess 
I'll go with the latter, then :) But one of the reasons I was thinking about 
outright removing toIR/toObjFile is because: don't they call into the 
back-end? So if I rip out the back-end, I would think those functions would 
just break at compile-time anyway. And if proper traversal chnges at all, 
then I'd need to change my external traversal. At least that's what I was 
thinking, anyway. Am I misguided on any of this?

> Why would you want to generate PHP anyway? There are FastCGI libraries 
> available for D, and there isn't much that D is missing and PHP has 
> anyway. Everything else is implementable as a library (and contributable 
> to Phobos! ;)

I definitely intend to do D/CGI/FastCGI whenever possible. But sometimes a 
client may insist on PHP and I may be unable to sway either them or their IT 
people, or they may be on a host that disallows or frowns on custom CGI, or 
whatever. Plus, with the project I'm working on right now (currently in 
Haxe, which gets compiled to PHP), the business guy's intent is to sell it 
to other groups who are likely to have their own server/web-host, and if I 
switch from Haxe to D without a way to convert D to PHP then I risk turning 
away potential buyers (and this is already a limited-domain sort of thing 
anyway).