On Thu, Feb 26, 2009 at 10:18 PM, Geoffrey Irving <[email protected]> wrote: > On Thu, Feb 26, 2009 at 6:58 PM, Jonathan S. Shapiro <[email protected]> wrote: >> 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. > > I'm not sure that's true. In the same email you noted that you could > express SSA form in BitC, and I assumed you were referring to the fact > that tail calls are essentially the same thing as SSA. If so, you can > definitely translate all of this into tail calls.
Yes. What i was trying to say is that we need to keep the primitive looping form in the language. >> Actually, in this case we can simply identify forall as a procedure >> whose inlining is mandatory and we're done. > > What if someone stores a reference to forall in a higher order variable? It's like they say in most militaries: if you can't take a joke, you shouldn't have joined. Serious answer: inline procedures aren't inlined unless references to them are statically resolvable. > If you want to talk processor architect, goto is the one true way. :) Well, yes. But branch-on-impending-error is cool too. :-) _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
