compile-time regex redux

[Walter Bright]

kris wrote:
> compile-time regex is only part of the picture. A small one too. I 
> rather expect we'd wind up finding the manner it was exposed was just 
> too limiting in one way or another. Exposing, as was apparently 
> suggested, the full API of RegExp inside the compiler sounds a tad 
> distasteful.

I tend to agree with that.

> You'll perhaps forgive me if I question whether this is driven primarily 
> from an academic interest?  What I mean is this: if and when D goes 
> mainstream, perhaps just one in ten-thousand developers will actually 
> use this kind of feature more than 5 times (and still find themselves 
> limited). Perhaps I'm being generous with those numbers also?
> 
> What is wrong with runtime execution anyway? It sure is easier to write 
> and maintain clean D code than (for many ppl) complex concepts that are, 
> what amount to, nothing more than runtime optimizations. Isn't that true?
> 
> It would seem that adding such features does not address the type of 
> things that would be useful to 80% of developers? Surely that should be 
> far more important?

Good question. The simple answer is look what Ruby on Rails did for 
Ruby. Ruby's a good language, but the killer app for it was RoR. RoR is 
what drove adoption of Ruby through the roof. Enabling ways for 
sophisticated DSLs to interoperate with D will enable such applications. 
Probably the only killer C++ Boost library is the Spirit library, which 
I have looked over with envious eyes. The way it works (expression 
templates) is incredibly difficult for library writers to create, and 
even the result is pretty quirky. But there's no denying how useful 
people find it.

So I feel that by enabling easy DSL writing, we open the door to a much 
wider range of libraries to be written for D, and making libraries easy 
to write is (I think we all agree) key to success.

It isn't at all about runtime optimization. It's about, for example, the 
ability to create a specialized matrix manipulation language, complete 
with user defined operators, etc., and have it 'compile' to regular D code.

> And, no ... I'm not just pooh poohing the idea ... I'm really serious 
> about D getting some realistic market traction, and I don't see how 
> adding more compile-time 'specialities' can help in any way other than 
> generating a little bit of 'novelty' interest. Isn't this a good example 
> of "premature optimization" ?

No, I don't think it is at all about optimization.

> Surely some of the others long-term concerns, such as solid debugging 
> support, simmering code/dataseg bloat, lib support for templates, etc, 
> etc, should deserve full attention instead? Surely that is a more 
> successful approach to getting D adopted in the marketplace?

Those are all extremely important, too.