"Nick Sabalausky" <a...@a.a> wrote in message news:i1i8o8$1kb...@digitalmars.com... > "Don" <nos...@nospam.com> wrote in message > news:i1h6br$2ng...@digitalmars.com... >> Rainer Deyke wrote: >>> On 7/13/2010 01:03, Nick Sabalausky wrote: >>>> "Rainer Deyke" <rain...@eldwood.com> wrote in message >>>> news:i1gs16$1oj...@digitalmars.com... >>>>> The great strength of string mixins is that you can use them to add >>>>> the >>>>> AST macros to D. The great weakness of string mixins is that doing so >>>>> requires a full (and extendable) CTFE D parser, and that no such >>>>> parser >>>>> is provided by Phobos. >>>> Seems to me that would lead to unnecessary decreases in compilation >>>> performance. Such as superfluous re-parsing. And depending how exactly >>>> DMD does CTFE, a CTFE D parser could be slower than just simply having >>>> DMD do the parsing directly. >>> >>> True. I tend to ignore compile-time costs. The performance of computers >>> is increasing exponentially. The length of the average computer program >>> is more or less stable. Therefore this particular problem will >>> eventually solve itself. >>> >>> Of course, this is just my perspective as a developer who uses a >>> compiler maybe twenty times a day. If I was writing my own compiler >>> which was going to be used thousands of times a day by thousands of >>> different developers, I'd have a different attitude. >>> >>> >> >> CTFE isn't intrinsically slow. The reason it's so slow in DMD right now >> is that the treatment of CTFE variables is done in an absurdly >> inefficient way. > > Doesn't it at least have some intrinsic overhead? The best way I can think > of to do it (in fact, the way Nemerle does it, and I really wish D did > too) is to actually fully compile the CTFE then dynamiclly link it in and > run it natively (erm, well, Nemerle is .NET, not native, but you get the > idea). Even that would seem to have a little bit of overhead compared to > just running code that's already built-in to the compiler (it has to > compile a chunk of code, and then link it, both of which take more time > than just calling an internal function). And if you're not doing it that > way then you're interpreting, which inherently adds some fetch/dispatch > processing. > > Yea, certainly it could be made to be fairly fast, and the overhead > doesn't *have* to be big enough to be noticable. But why not just do it > the *really* fast way right from the start? Especially in a language like > D that's supposed to have an emphasis on short compile times. >
Plus, there's the whole duplication of code: D parser in C++, plus a D parser in D CTFE.