On Mon, Mar 2, 2015 at 6:50 AM, Keean Schupke <[email protected]> wrote:
> I have a question. I import an arity-concrete function from 'C' that: > > test :: fn 2 'a 'b -> 'c > > I apply it like this: > > ((test 1) 2) instead of (test 1 2). > > Do I care? As long as the intermediate (test 1) is a temporary value (in > the C++ sense), it does not cause any problems as it cannot escape, and > gets the (2) applied to it right away. > In principle I agree that this is fine. In BitC it is a syntax error, because you are relying on the optimizer to restore a correct concrete application, and the optimizer may be entirely turned off. Also, your "temporary" value allocates a closure object. You are tacitly assuming that this can be stack-allocated, but nothing in the language semantics allows you to do that. You are also teetering here on a different problem. You're arguing here that a heap allocation can be moved to the stack by optimization. I agree that it *can* be, and I agree that in this particular example that optimization can be done 100% of the time. Separately, you ague that optimization must always be non-semantic. It would follow that optimization should never alter the types of things. But you are arguing here that we can justify eliding the HeapAllocates effect on the basis of an optimization. I claim that if optimizations are non-semantic, then the HeapAlloc effect cannot be removed, even if we can perform this particular optimization 100% of the time. BitC *never* gets to rely on the optimizer to put things right. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
