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