You can always include licence restrictions, to the effect that all program type signatures are public domain. In my system module signatures are just plain types.
Keean. On 3 Jun 2015 19:00, "Matt Rice" <[email protected]> wrote: > On Wed, Jun 3, 2015 at 5:14 AM, Jonathan S. Shapiro <[email protected]> > 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 > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
