DIP30, delegates more destruction for your pleasure

Dmitry Olshansky dmitry.olsh at gmail.com
Thu Mar 14 10:11:45 PDT 2013


14-Mar-2013 20:45, Timon Gehr пишет:
> On 03/14/2013 06:59 AM, Maxim Fomin wrote:
>> On Thursday, 14 March 2013 at 05:29:25 UTC, deadalnix wrote:
>>> On Thursday, 14 March 2013 at 05:12:51 UTC, Maxim Fomin wrote:
>>>> ABI, at least partly, is and should be part of the spec. Otherwise it
>>>> has some of the C++ problems. And the point was not about ABI in a
>>>> sense of adding piece of information to chapter in dlang.org, but
>>>> about implementing compiler. I am not enthusiastic about most DIPs
>>>> presented recently because 1) without Walter and Andrei approval 2)
>>>> without somebody willing to implement it, DIP turns to be a paper
>>>> intellect exercise and corresponding ideas defence in the forum.
>>>>
>>>
>>> Timon Gehr and I are working on compiler. This isn't intellectual
>>> masturbation.
>>
>> And without significant usage it is a coding exercise or NIH syndrome.
>
> There's a significant amount of easy-to-implement language features
> missing.
>
>> What is good in the compiler (brand new frontend?) relative to
>> gdc/ldc/dmd? Why somebody would switch to it?
>>
>
> I do not care whether someone switches to it, but the plan is:
>
> * Diagnostics
>    - Nicely formatted: Yes.
>    - Useful diagnostics for template instantiation failures: TODO
>
> * CTFE
>    - Working: Yes (eg: full support for closures.)
>    - Fast: Partly done. (the implementation is not as horribly slow as
> DMD's.)
>
> * Sane and well-defined treatment of complex analysis dependencies.
>    - Makes sure that is-expressions are consistent and unambiguous
>      throughout compilation.
>    - To the point diagnostics.
>    - dlang.org spec and DMD frontend fundamentally broken in this regard.
>    - Mostly works already.
>
> * Complete independence of compiler backend
>    - (In fact, there is no backend yet, CTFE is sufficient for testing.)
>
> * Easy-to-use minimal wrapper library
>    - Enabling frameworks for program analysis.
>    - Simple plugging of custom back ends.
>    - Not done yet.
>
> * Using the front end in a code editor
>    - Incremental compilation. (Change only code gen of the function that
>      was last accessed.
>    - Display of semantic information.
>    - Not done yet. (But the design of the front end will
>      support such endeavours nicely.)
>
> * Short to-the-point code. Written in D.
>

Dunno about others but I'm sold.
In fact, I was since I've first heard about it.


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list