GSoC 2013: CfM (Call for Mentors)

[Don]

On Sunday, 24 March 2013 at 20:37:36 UTC, Adam Wilson wrote:
> On Sun, 24 Mar 2013 08:52:45 -0700, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Hello,
>>
>>
>> Google Summer of code 2013 is accepting applications. Just 
>> like in the past years, we need a few mentors to ensure a 
>> successful event.
>>
>> This year we plan to get significantly better organized and 
>> make sure the event is successful in measurable ways 
>> (finalized projects or committed contributions to 
>> dmd/druntime/phobos etc). We have made a mistake in the past 
>> of approving the GC project by Antti-Ville Tuuainen who 
>> subsequently became unreachable to follow through with merging 
>> his project in the mainline. We don't want to repeat such 
>> mistakes in the future, which means a closer, stronger 
>> mentor/mentee relationship.
>>
>> So please reply to this or email Walter and myself if you have 
>> the time and inclination to mentor a student this summer. For 
>> a detailed mentor's manual, peruse 
>> http://en.flossmanuals.net/GSoCMentoring/.
>>
>>
>> Thanks,
>>
>> Andrei
>
> Count me in! I really enjoyed last years edition and I'd 
> definitely be up for doing it again this year. Although I would 
> be willing to work with anybody that has a good idea, I think 
> Mr. Bothe has an interesting idea for this years work. 
> Compiling D to CIL would be a huge boon to Mono-D as it would 
> make real-time CTFE evaluation a reality. Or at least get us on 
> the right path. We'll have to hammer out what can actually be 
> done in three months.

The reason why CTFE real-time evaluation hasn't happened yet, 
isn't related to that. It's not particularly hard to do JIT it. 
You probably imagine that the CTFE engine is given a syntax tree 
which has been semantically analyzed, and just has to compile it 
and run it. Just like a backend. Unfortunately, that's not the 
case.

The problem is rather that the interface between compiler and 
CTFE is very, very messy. So the challenge is knowing what to 
JIT. Basically, in the compiler, the evil lies in a file called 
optimize.c which is sort-of part of CTFE, and sort-of not, and 
has very complicated behaviour.

For example:
static int k = [1,2,3] [  $ - 2 +  { return $-2; }() ];

The delegate literal gets evaluated in CTFE. But, $ exists 
_outside_ the delegate literal.
There were literally more than a hundred of these corner cases. 
I've been working on them for well over a year, I'm close to 
getting them all.
Until this is done, attempting to compile CTFE code would be an 
exercise in frustration. You'll get it to work in 95% of cases, 
and then fail miserably with the rest.
Right now, this project is a trap.