On Wed, Oct 16, 2013 at 6:16 PM, Jonathan S. Shapiro <[email protected]>wrote:
> I suspect it's almost entirely due to string data, and almost everything > else gets mutated. > > The main reason it's of interest is that forwarding a frozen object is > very easy; you don't care which version the client code operates on, > because neither is changing, so you don't need a barrier. > > What I'm really wondering here is whether a "frozen" bit in the object > header would have much payoff. I suspect that with additional source > language emphasis on immutability it might. > > > shap > I think this will depend a lot whether the standard library and standard idioms are oriented towards functional except where performance requires. Rust for example seems to be going in a different direction, for example, where standard practice includes a lot of borrowing and controlled mutability. In addition to making frozen-based optimizations difficult, it seems to be a source of a lot of complexity and difficult to understand corners of the borrowing system; nearly all of the mailing list threads while I was subscribed were people trying to shoehorn their type of mutation into the Rust type system. >From a scalable programming standpoint, it would be wonderful if bitc steered users towards mostly functional programming, or specifically towards "advanced" versions of mutate only during init. What I mean by advanced is that frequently the initialization might take place across several functions or involve a bunch of expensive looping, but typically the pointers to mutable objects during this process are "nearly linear" in that the mutable objects haven't been assembled into more complicated data structures yet. The rust type system can do this too, to some extent, but they seem to be emphasizing more general mutability idioms (and then paying for it). 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. Geoffrey
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
