On Mon, Feb 23, 2015 at 3:35 PM, Matt Oliveri <[email protected]> wrote:
> On Mon, Feb 23, 2015 at 1:04 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > This is actually worth talking about for a moment. BitC requires "no > > implicit allocation", so we can't adopt the curried function definition > > model. That's part of why we can't just re-write > > > > def f x = \y. x + y > > > > as an arity-2 function definition. We can do that rewrite as an > > optimization, but not as a definitional rewrite. > > What's the difference? Optimizations don't affect the language as > specified? > If the optimizer can see the definition and the site of the application, it is certainly free to implement this as an optimization. What I'm trying to say is that the compiler cannot implement this transform as a matter of policy at the instant it sees the definition (which is what F# does). The developer has written the function with a specific arity. The ocmpiler must respect that unless it can prove that a transform preserves semantics. In this case, rewriting the function as an arity-2 function as soon as we see the definition might later induce allocation when the function is applied to a single argument and is therefore forced to have a closure. > > Consider a "normally" curried language like Haskell. We've established > that > > we can invent an arity-inference approach that works at definitions, and > > we've further established that we can propagate arity through > > specialization. Fine. But an *advantage* to currying, from an > optimization > > point of view, is that the closure formations *aren't* driven by an > explicit > > lambda construct. Instead, they are introduced by the compiler at the > > application site and therefore easily visible to the optimizer. For this > > reason, they can pretty easily be lifted and re-written away, or they > can be > > stack-allocated using a region discipline, or the records they construct > can > > at least be elided to eliminate intermediate steps. All of this can be > done > > without looking at the insides of the actual function definition once we > > know its arity. > > > > The point I'm making is that explicit control over allocation is not > > necessarily the best choice for optimization purposes in all cases. For a > > systems language, control is intentionally prioritized over optimization, > > but we shouldn't be blind to the trade-offs that this policy entails. > > Point taken. But is this an argument against application-driven > specialization? It doesn't seem like it, but you started by saying > definitions should be arity-concrete, which would rule it out. That wasn't my intention. It was just taking note that some optimizations are possible in true currying that it's easy to forget about. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
