On Thu, Feb 26, 2009 at 8:10 PM, Geoffrey Irving <[email protected]> wrote: > Unfortunately, since there is no primitive language construct for > looping other than tail-recursion, efficient compilation of any higher > order construct like forall requires partial specialization, not just > inlining. It might not be too bad since the partial specialization is > almost inlining in the sense of being inlining that results in tail > recursive structures, but still scary.
But BitC has (and will retain) a first-class looping construct. We saw this particular oncoming train early. We also have labeled block escape, which is sometimes useful in these situations. > I think that as a user of the language, I would only feel secure if I > could be completely sure that the important usages of forall were > partially specialized. Yes. The way I sometimes try to express this is that certain simplifications of the language are only acceptable in practice if we can successfully specify and mandate the corresponding optimizations that make them efficient. But there is another hidden issue here: it is most unfortunate if the implementation of these optimizations cannot be done by a BitC->BitC transform. I touched on this in a note a day or so ago in the context of unboxing. This is another good example. > This means ... partially specialize every > occurrence of forall. Neither one is very attractive. Actually, in this case we can simply identify forall as a procedure whose inlining is mandatory and we're done. > Actually, a syntactical for-loop construct _is_ a programmer annotated > version of forall, so that might be the way to go.... I tend to see it the other way around. Forall is a convenience syntax around a syntactical for-loop construct. But that's the processor architect in me talking. I think we're in peaceable agreement about all this. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
