On 2 March 2015 at 15:26, Jonathan S. Shapiro <[email protected]> wrote:
> 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. > Okay, so I think I am convinced on this point. For an arity-concrete type the applications must not be less than the required arity. But presumably we are okay the other way around where I write: f a b c for a function : fn 1 'a -> fn 1 'b -> fn 1 'c -> 'd, we are not going to force people to write: ((f a) b) c Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
