On Wed, Oct 16, 2013 at 8:50 PM, Geoffrey Irving <[email protected]> wrote:
> I think [the utility of RO objects] will depend a lot whether the standard > library and standard idioms are oriented towards functional except where > performance requires. > That certainly helps. It also helps if the source language simply lets us express and enforce init-only fields and read-only objects. A 5% shift in the tenured heap in favor of read-only objects could make a very noticeable overall performance difference. >From a scalable programming standpoint, it would be wonderful if bitc > steered users towards mostly functional programming... > That isn't the purpose of bitc. The purpose of bitc is to support high-performance systems programming. All of the really important stuff in such programs is stateful. Unfortunately, idioms like monads don't compose well and don't address concurrent execution requirements. I'd love to see active support for functional-style subprograms. The concern I have is that (a) it multiplies the complexity of the standard library, and (b) the notion of read-only turns out to be a very complicated notion if you want to do it well. Summary: I think emphasizing mutate for a while then freeze is wonderful > from a software engineering standpoint over and above the garbage > collection performance issues. > Concur. And I think that's still true if you have to go through phase changes where an object becomes mutable again, which seems to arise in some concurrent programming idioms. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
