[for convenience, I'll be using 'ttree' to refer to the hypothetical gradually-typed tree system and its central type]
Martin Uecker <[email protected]> writes: > I do not think so. Alone the compile-time cost of templates makes this > a bad trade-off in my opinion, and I find compilation time already to > be problematic for GCC. That's a reason to improve the GCC implementation of templates (of course, no easy feat), not to make GCC less maintainable. We already have a relatively small base of active developers, and a yet smaller base of reviewers. Having fewer tools for writing correct code, having fewer type annotations for new developers, and having more latent bugs are all very bad ideas. The first means more time needs to be spent verifying and re-verifying changes, which directly decreases effective review capacity. The second means new developers must spend more time figuring out types that can be passed in given places, which they will get wrong, and which will demotivate them. The third means more bugs go uncaught and more time is spent fixing those that do get caught. I'd be fine with gcc build time tripling or more to reduce those factors. That said, there's no reason why we couldn't make it possible to essentially disable the 'tree' type checking. I don't think that's worth it, frankly, and I think it adds to the combinatorial explosion that is GCC build-time configuration, but we could explicitly make it so that 'ttree' with, say, checking disabled, compiles down to: template<typename...> using ttree = tree; Hence, short-circuiting all or nearly all cost. When I was initially thinking about this problem, I did put this down as a design goal for a different reason: showing that GCC would compile to the same machine code anyway even with this typechecking added, thus making it easier to approve the patch series. I'm now of the opinion that this original goal of mine isn't worth it, especially as we could use 'ttree' to provide member accessors to increase the level of assistance that can be provided by editors and/or decrease verbosity (discovering what the correct accessor is for some part of some tree_code is a bit of an art even today; this also did come up in the C++ NAS patch, where TREE_LANG_FLAG_... was being used incorrectly - this, too, could've been prevented, but luckily Thomas caught it in review). Of course, the latter is also impossible in case we do this short circuiting for sake of compilation time. I really do wish I had a partially done example, so that we could do some empirical study on this. But, alas… > I agree that catching errors at compile time is good, but in > many cases this can be achieved in C just as well. I usually find > that people underestimate what can be done in C alone. Clearly, C++ > allows you to do more sophisticated typing (I wrote for some time > expression-template libraries before I decided that this just takes > too much of my time). Being clever with C++ templates is - in my > experience - usually a bad trade-off as the cost in complexity and > compilation times exceeds the improvements in type safety you can > achieve in this way. Please implement a conversion operator in C. Adjusting 'tree' is a non-starter without those. Then, we'll also need packs of types and of heterogeneous values that can be manipulated at compile-time, to represent sum types. > I agree, but the untypedness of tree is not the fault of C... I agree, but I never said that it was. Just that we can't fix it in C in a viable way. > ... and changing this would not require switching to C++. It would. There is no method by which we can implement correct rules for gradual typing in C. Especially not earlier versions of C. > It would simply require to introduce C types for each specific node > type. The "simply" here is doing a lot of heavy lifting. There's nothing "simple" about changing *the* core type of a 3 million LoC codebase. As I said, gradual typing is the only alternative to dynamic typing possible for GCC today. C lacks user-defined conversions; this alone makes it impossible to implement gradual typing in C. I also highly doubt that _Generic would be able to perform the operations necessary to check for, say, overlaps of two sum types (i.e. whether two different instances of what I called 'one_of' in my original message contain each-other), which would be necessary to determine whether a conversion is safe. I also have to wonder whether the tokens emitted by the hypothetical requisite macro soup would end up being slower to compile than the equivalent template soup. I seem to recall some article on LWN about macro expansion cost being a real problem for Linux, but I can't find it now. -- Arsen Arsenović
signature.asc
Description: PGP signature
