Hacker News Reader

Comment by tom_mellior | Hacker News Reader

> I don't think that programmers want big loops to unroll.

Right, well, it depends. That's why I think unconst should be the default and unrolling should be requested explicitly by using something like

    let fib_2000 = specialize (fib 2000)

where specialize is a language built-in that triggers the unrolling. And then, if the user really does want you to specialize fib 2147483647, it would honor that too, without your arbitrary unrolling cutoff. And if it takes too long, well, the user wanted it that way. That is user control. Arbitrary hidden cutoffs are not.

View on HN

unconst can't be the default because there is no way to re-const a value once it's been turned into an unknown. The most "automagic" behavior is to tie branch conditionals to their exit values (there's a helper function called tie-const that does this for the manual case). If the conditional is unknown at compile time, then the continuations that exit the branch will mark their arguments as unknown. That also stops loops from unrolling (they'd typically unroll for i=0, but then stop). But, as I mentioned before, that completely kills constant folding at the exit points, something that is at times desirable.

Another reason loops are unrolling by default is that there are many situations where constexprs have to completely fold at compile time, and you need a guarantee that they do. A common example is handling keyed varargs. You need to be able to iterate through the keys and build local variables from that without any code being generated.

If a compile time unroll takes forever, there's practically no clean way to debug that.

On the other hand, I like unconst on first sight. A symmetrical form to do specialization would be nice too. What about making the loop unrolling configurable, whether with a compiler flag or some form like Lisp's declare.

Reply on news.ycombinator.com