There are a couple of aspects of this particular approach that intrigue me with a kind of horrified fascination. In fairness to Matt Bierner (the author), let me say right off that he's done something very interesting using the only tool available to him given his decision to do a C++ implementation.
I'm horrified at two levels: Anybody with half a brain is horrified by the surface syntax of C++ templates, so let's not dwell on that part. As a tool for making simple things obfuscated, it's really hard to beat. :-) I think what disturbs me is really in two parts: the use of type resolution to drive compile-time computation (this is currently the only choice for that in C++), and the clever [ab]use of the type resolution and promotion rules. I might not feel such a compelling need for a shower if this stuff wasn't being pushed into type-level computation for the sake of an [admittedly important] efficiency. But you use the tools you have. Keean exploits this sort of thing in his combinator library as well. The other issue that horrifies me really isn't about combinators - or this example - at all. It's the implications of compile-time computation. BitC was starting to move in that direction as well, because of the desire to support richer initializers and immutable data structures. The C++ const_expr notion is a step in this direction. My concern comes from a security perspective. When a program can be richly rewritten at compile time, it becomes very easy to introduce hidden security issues. So: compile-time computation yes, but macros no. And yes, I realize that there has been a lot of work on cleaner macro systems. I'm not saying it's impossible to arrive at reasonable ground. I'm only saying that it makes my head hurt to think about it. The other thing that kind of disgusts me about the template thing is that nobody seems to be taking it to its logical conclusion. We have a turing-complete language in the template system! Why not actually go ahead and compute the parse tables at compile time too! :-) Now *that* would be a stupid template trick! shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
