on Sun May 22 2016, Matthew Johnson <swift-evolution@swift.org> wrote:
> Are you sure that is Sean’s entire point? I take more away from it than that. > Look at slide 13 here: > https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value_semantics/value_semantics.pdf > > “The shared structure also breaks our ability to reason locally about code”. > > But I know you agree with that as well as you indicated just up thread. > > It sounds like the only remaining point of possible disagreement is whether > “can’t reach shared mutable state” is a reasonable constraint to place on > types > in generic code. Here's what Sean sent me this morning: > Hi Dave, > > I've now had several people send me this transcript. I'm not seeing > > Although I'm sure you know this - the short definition of regular is: > > copies are equal and logically disjoint. > > Logically disjoint means that modifications to one copy do not modify > other copies. It does not mean "no sharing" - sharing of an immutable > part, a copy-on-write part (immutable when shared) or a part which is > outside the definition of equality (such as a cache) are all > allowed. We can write out all the axioms for a regular type if that > would help. I do not know what the axioms of a "pure value" are, or > how they would differ from this definition. Typically in functional > programming (where "pure" is used to refer to functions that have no > side effects) a value is not mutable and so the notion of disjoint > does not come into question and there is typically significant > sharing. > > For "pure value" to be a useful concept we need an instance of a > model, an algorithm that relies on the additional requirements, and > the axioms that define it. From the thread it seems as if the > definition is something like "copies are equal and physically > disjoint." I'm not sure if there is something else people are trying > to say along the lines that all parts are included in equality. I do > not see any compelling evidence in the description that there are > useful algorithms that rely on such attributes. Note that concepts are > about enabling additional algorithms, including for efficiency. > > [ Feel free to quote this back to the list - I can be easily reached > at spar...@adobe.com if people have questions instead of speculating > about what I did, or did not, mean in my talks. ] > > Sean ...and now, I really need to get back to work on *my* talk for WWDC. Cheers, -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution