ctfe library

[Don]

Ellery Newcomer wrote:
> On 04/20/2010 10:17 AM, Don wrote:
>>
>> I don't see anything particularly ugly or hacky about CTFE code, like
>> the code below:
>>
>> int greater(int a, int b) {
>> if (a>b) return a;
>> else return b;
>> }
>>
>> int [ greater(short.max/3, 515) ] foo;
> 
> It isn't. Things don't get ugly until you hit the relatively low ceiling 
> of what ctfe can handle. I don't pay much attention to where that 
> ceiling is, but I am aware that the situation has been improving mostly 
> due to your efforts, and I appreciate that.
> 
> So far, all my ctfe code is code generation for string mixins, and it's 
> fairly modest stuff, to the point where a simple string formatting 
> function could probably take care of a fair portion of the problem. It's 
> just that I don't know of any. (I'm in D1/Tango land)
> 
> The other half of the problem is parsing input strings for simple dsls. 
> Having to write out a lexer/parser from scratch just sucks regardless, 
> and writing it in ctfe code, which isn't allowed composite data 
> structures (last I checked) is really not worth doing. 

Now that it can do struct member functions and delegates, it's possible 
to do fairly sophisticated things in CTFE. Unfortunately the two killer 
bugs (bug 1330 and 1382) still aren't fixed, so the frustration level is 
still pretty bad. We're still a few releases away from getting a fix for 
those ones.

I think D fails
> on its promise here, where it says "with string mixins you can create 
> your own dsls", but then provides no additional support.

Yes, the two CTFE bugs I mention are blockers. Once they're fixed, it 
will be fairly simple to add support for classes, exceptions, and nearly 
everything else.

> 
> As ctfe support matures, I dream of a full-fledged parser generator that 
> can be evaluated at compile time, although that's way more heavy duty 
> than what most people will need.
> 
> Another idea is something more on the lines of haskell's parsec, which 
> provides building blocks for common tokens, etc. I don't know much about 
> it, though.
> 
> Even compile time regular expressions would be better than nothing..
> 
> And whatever it is, it needs to be in the standard library.

Exactly.