ctfe library

Ellery Newcomer ellery-newcomer at utulsa.edu
Tue Apr 20 09:12:49 PDT 2010


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. 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.

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.


More information about the Digitalmars-d-learn mailing list