I would think option 2 was preferable. By the way, I find it interesting that there's a difference on how you care about mutability of arguments depending on if you are constructing data or if you are just reading data.
In the case of a function that just reads (deconstructs) data structures (at least in a single-threaded setting), you don't care if the data is immutable or not. The optimizer could care a little, in that if it is known that the data is not mutated, it could cache results (e.g. the result of your s_length function). However, when passing references to data structures to a constructor that is supposed to produce immutable data, then it is vital that the arguments are actually immutable. Otherwise, we'll end up with Jonathan's fear - in that you will surprise the programmer, getting us in a situation much like C++ where "constness" means nothing, even for the optimizer. Is there some kind of duality principle going on? Thanks, PKE ________________________________________ From: [email protected] [[email protected]] On Behalf Of Sandro Magi [[email protected]] Sent: Thursday, March 24, 2011 7:22 AM To: Discussions about the BitC language Subject: Re: [bitc-dev] Mutability, again I should amend this because I understand you're worrying about the alleged mutability of S in this example, and I suppose it depends on how you collect the properties: if taking a ref to Container.s returns a "ref S", where S looks immutable, this is clearly not correct. There are two possibilities here: 1. You forbid taking a ref to a mutable field, unless the structure it points to is also mutable (mutable to only one level is probably sufficient). 2. Taking a ref to a mutable field returns a "ref mutable S", ie. you collect *all* the properties along the path when constructing a ref. This is the only maximally flexible option that I can think of. Sandro On 24/03/2011 10:14 AM, Sandro Magi wrote: > On 23/03/2011 5:56 PM, Jonathan S. Shapiro wrote: >> Among other consequences, this means that in a language having init-only >> fields and inner-references, a structure consisting exclusively of >> init-only fields is not necessarily pure... > > I'm not sure the example implies this conclusion. 'Container' clearly is > not init-only. Is it really surprising that introducing mutability > anywhere in a path means the purity of our immutable structures changes? > > Use of mutability, inner refs, etc. merely need to be possible and > sound. The example you provided is a hazard of working with any sort of > mutability, and I wouldn't fret over it. > > Sandro > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
