compile-time regex redux

[kris]

Andrei Alexandrescu (See Website For Email) wrote:
> 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.
> 
> 
> Au contraire, I think it's a definite step in the right direction. 
> Writing programs that write programs is a great way of doing more with 
> less effort. Various languages can do that to various extents, and it's 
> very heartening that D is taking steps in that direction. Allowing the 
> programmer to manipulate strings during compilation is definitely a good 
> step.

You're saying that a 'normal' D program is not sufficiently powerful to 
write other programs?  Au contraire!  There's nothing wrong with doing 
that at runtime, rather than turning the compiler itself into an 
abstract virtual machine?

> 
>> 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?
> 
> 
> Perhaps, just like me, you simply aren't in the position to evaluate 
> them. I will notice, however, a few historical trends. C++ got a shot in 
> the arm from the STL. STL = advanced programming. Interesting. The STL 
> did much to educate the C++ community towards code generation, which 
> continues to be the reason why many influential gurus hang out with C++.

Are you saying that adding regex support at compile-time will take the 
world by storm? I hope not, because STL and its ilk are about 
productivity for a mass audience. Not for the few who work with DSL on a 
regular basis. Besides D is perfectly capable of DSL handling at 
runtime; there's just no overpowering need for it to do that at 
/compile-time/.

We might as well be discussing whether the compiler should embed a GUI 
generator. So it can be used at compile-time. There are better ways of 
doing that. Ways that are more accessible, more maintainable, and have a 
much easier learning curve. The OSX GUI builder is one fine example.


> To survive, D must compensate for its relative lack of clout and 
> publicity by offering above and beyond what more mainstream languages 
> offer.

To survive, D needs to get serious about being taken seriously.

Concentrating on what /might/ become a niche ideal doesn't strike me as 
the best approach. Compare and constrast with, say, targeting D for 
cell-phone devices? It's the biggest market on the planet, just sitting 
there /waiting/ for D to come along with the right set of features.

> 
>> 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?
> 
> 
> No. Accommodating DSLs and generating code has more to do with 
> correctness and avoiding duplication of source code, than anything else.

Yes and no. I will defer, of course, to your experience in the matter; 
but will note that there's /always/ a point of diminishing return.

> 
>> 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?
> 
> 
> No. You are missing a key point - that some code is more influential 
> than other. 2% of programmers may write libraries that work for 90% of 
> programmers.

Indeed. I'm partially responsible for a rather large library. And 
there's no way that I can see a use for this feature in there. That 
doesn't mean it won't get used by somebody somewhere (of course), but I 
put it to you that it does indicate just how little need there is for 
such features in the language (at compile time).

Yes, I'd personally like to see some better template handling. I'd like 
to see IFTI fixed - not some new feature that this (extensive) library 
will never use :)


> a "white hole" class is an implementation of A that implements all 
> methods to throw, and a "black hole" class is an implementation of A 
> that implements all methods to return the default value of the return type.
> 
> This pattern is very useful for either quick starting points for writing 
> true classes implementing A, or as standalone degenerate implementations.
> 
> To some programmers, black and white holes might not even raise a 
> "duplicated code" flag. They sit down and write:

That could reasonably be argued as a point of diminishing return? If it 
takes more effort or knowledge of how to abstract the pattern from two 
or more concepts, and to implement it using something unfamiliar, then 
99% of developers will ignore it completely.

I fully agree that /idealistically/ such patterns would be nice to have, 
but that's not reality. And I can't see how this could possibly help D 
get notable traction, since it can also be done using the tools already 
available in D: contracts via interfaces or abstract base-classes.


>> Lot's of questions, and I hope you can give them serious 
>> consideration, Walter.
> 
> 
> I think it's good to be sure only when there's a solid basis.

Yes, I agree. Does that work both ways (serious question) ?

- Kris