compile-time regex redux

[Andrei Alexandrescu (See Website For Email)]

kris wrote:
> 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 don't understand. Code generation is only interesting when the 
generated code works together with handwritten code and lives within the 
same symbolic ecosystem.

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

I tried to provide solid argumentation and/or evidence for my 
statements. The post I replied to originally, and the post I am replying 
to now, use rhetoric and bare statements somehow implying they are drawn 
from common knowledge. I will not simply agree with a bare statement 
claiming that this is not needed or that is not necessary.

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

Exactly what is anyone to make of this? Reminds me of Jerome K. Jerome: 
"Never do something shameful, my son," the mother said, "and then you'll 
never be ashamed of what you did."

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

Sure if there are abstractions of interest to embedded programs they are 
worth discussing. But again, leaving it at the level of Zen statements 
is only empty rhetoric.

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

To this I'll insert the obligatory answer that that's a truism.

>> 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 think any developer can write an alias statement. The point of the 
example was to illustrate how an advanced feature can be used by an 
expert to democratize efficient development.

Abstraction is hard, no question about that. (Another truism. :o)) The 
problem is that often, even when the abstraction is understood, 
reflecting it in code is a complete mess.

Walter gave another good case study: Ruby on Rails. The success of Ruby 
on Rails has a lot to do with its ability to express abstractions that 
were a complete mess to deal with in concreteland.

> I fully agree that /idealistically/ such patterns would be nice to have, 
> but that's not reality.

I'm not sure what this statement is based on. For example, there are 
Perl libraries for white holes and black holes:

http://cpan.uwinnipeg.ca/htdocs/Class-BlackHole/Class/BlackHole.html
http://cpan.uwinnipeg.ca/htdocs/Class-WhiteHole/Class/WhiteHole.html

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

This reflects misunderstanding of the stakes. Interfaces and abstract 
base classes are a recipe for _handwritten_ code. black_hole and 
white_hole are tools that generate code _mechanically_.

>>> 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) ?

I did my best to explain the basis of my opinions.


Andrei