BitC, Rust, dog food and more

[Nick Sabalausky]

"deadalnix" <deadalnix at gmail.com> wrote in message 
news:jko00q$1pif$1 at digitalmars.com...
> Le 25/03/2012 22:38, James Miller a écrit :
>> On 26 March 2012 08:41, Nick Sabalausky<a at a.a>  wrote:
>>>
>>> Because you're cleverly using very D-like C++ ;)
>>>
>>
>> Unsurprising from, you know, the creator of D...
>>
>> That said, having a D compiler in D would be cool, simply because
>> every language needs a bootstrapped compiler :P. Also, their are other
>> arguments that apply well to bootstrapped compilers, like improving
>> the language improves the compiler, which improves the language. It's
>> also a complicated enough endeavour that it showcases D well. I don't
>> think that we should replace DMD with it, but it would be a cool
>> project.
>>
>> --
>> James Miller
>
> ddmd seems to provide a working frontend written in D. I think this 
> project should be more promoted (eventually become the main d frontend ?).

The problem with ddmd (at least the original, as opposed to the newer 
ddmd-clean fork) is that the approach it used for incorporating new changes 
from dmd proved to be unsustainable.

I think ddmd has, unfortunately, proven that the only realistic approach to 
having a full D compiler (or frontend) written in D, would be for dmd itself 
to just take the plunge and migrate to D. (And in the meantine, if someone 
wants a whole D frontend that's accessible from D, they're better off with D 
bindings to the C++-based D frontend.) But of course switching dmd from C++ 
to D could create difficulties with bootstrapping. For example, porting it 
to a new platform would require using an existing D cross-compiler. It'd 
mostly just be braggng rights anyway, and we have more important things to 
address (like iOS/Android IMO). Heck, Haxe is doing pretty well for itself, 
and it's not self-hosted, it's written in ocaml.

As far as ddmd-clean, that might be ok since it's just lex/parse, not 
semantics, and the lexer/parser doesn't need to change much. But once you 
add the semantics/CTFE/etc in there, then the approach of "developed in 
parallel in two different langauges" is just too impractical.