DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky

[Colin via Digitalmars-d-announce]

On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote:
> 12-Jun-2014 03:29, Adam D. Ruppe пишет:
>> On Wednesday, 11 June 2014 at 18:03:06 UTC, Atila Neves wrote:
>>> I wish I'd taken the mic at the end, and 2 days later Adam D. 
>>> Ruppe
>>> said what I was thinking of saying: unit test and debug the 
>>> CTFE
>>> function at runtime and then use it at compile-time when it's 
>>> ready
>>> for production.
>>
>> Aye. It wasn't long ago that this wasn't really possible 
>> because of how
>> incomplete and buggy CTFE was, you kinda had to do it with 
>> special code,
>> but now so much of the language works, there's a good chance 
>> if it works
>> at runtime it will work at compile time too.
>>
>> I was really surprised with CTFE a few months ago when I tried 
>> to use my
>> dom.d with it... and it actually worked. That's amazing to me.
>>
>> But anyway, in general, the ctfe mixin stuff could be replaced 
>> with an
>> external code generator, so yeah that's the way I write them 
>> now - as a
>> code generator standalone thing then go back and enum it to 
>> actually
>> use. (BTW I also like to generate fairly pretty code, e.g. 
>> indentend
>> properly, just because it makes it easier to read.)
>>
>
> And these couple of minutes are more like 30 minutes at a 
> times. Worse yet unlike proper build system it doesn't keep 
> track of actual changes (same regex patterns get recompiled 
> over and over), at this point seamless integration into the 
> language starts felling like a joke.


Maybe a change to the compiler to write any mixin'd string out to 
a temporary file (along with some identifier information and the 
line of code that generated it) and at the next compilation time 
try reading it back from that file iff the line of code that 
generated it hasnt changed?

Then, there'd be no heavy work for the compiler to do, apart from 
read that file in to a string.