On Wed, Jun 3, 2015 at 5:14 AM, Jonathan S. Shapiro <s...@eros-os.org> wrote: > 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!
I find another aspect troubling as well, (I've said it before but it may be worth repeating) from a copyright perspective and interoperability oracle vs google being a case which lacks over API which lacks expression, including expression in the type structures brings even more uncertainty over copyright, such that the expression and the type are inextricable, to a degree that the type and the expression may be subject to the copyright merger doctrine where the expression is no longer copyrightable... I completely fail to come up with any reasonable rules by which the courts can distinguish, and imagine that the pendulum may swing a while between both over and under protection of copyrights, we've seen this already without the added complexity of higher-order computations... but I have no idea what to expect from a court as either a consumer or producer of type level metaprogramming... _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
