You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just to elaborate, "pure" means "as pure as the borrow check needs a pure function to be"... which is a weaker notion than referential transparency, and isn't the same kind of "pure" that typestate would want either.
I was surprised to learn that vec::append*() are marked pure while effectively altering the lhs (after overtaking ownership).
That's more like D's "weak purity" than Haskell's purity: http://leonardo-m.livejournal.com/99194.html
I am not persuaded that a new keyword is needed. Pure means that the function itself does not make changes to data it does not own. We have a slight generalization because we allow the function to invoke closures that are given as arguments, so in fact a function declared as a pure is parametrically, or conditionally, pure---"as pure as the closures it is given as arguments".
@catamorphism is correct though that this is insufficiently strict for typestate. To be correct, typestate must prohibit reads from non-owned, mutable state. (Also, of course, for a type state predicate to be considered pure it is not enough that it calls a pure function, it must also not supply only pure closures as arguments)
Two points from discussion on IRC: 1. It seems like "does not make changes to data it does not own" does amount to referentially transparent, as long as all higher-order function arguments are also referentially transparent (conditionally pure, as @nikomatsakis says). But this is fairly subtle and should be documented, or else people are going to look at a function and ask "how can this be pure, it mutates data?!" 2. The "conditionally pure" part is probably the most confusing thing. I'm not sure most people think "pure" means "as pure as its arguments". So I'm still in favor of changing the keyword.
There doesn't seem to be much interest in changing the keyword, and now that we no longer have typestate we no longer have the motivating reason that there are two notions of purity. So I'm closing.
Activity
catamorphism commentedon Jun 29, 2012
Just to elaborate, "pure" means "as pure as the borrow check needs a pure function to be"... which is a weaker notion than referential transparency, and isn't the same kind of "pure" that typestate would want either.
kud1ing commentedon Jun 29, 2012
I was surprised to learn that
vec::append*()are marked pure while effectively altering the lhs (after overtaking ownership).That's more like D's "weak purity" than Haskell's purity: http://leonardo-m.livejournal.com/99194.html
nikomatsakis commentedon Jul 5, 2012
I am not persuaded that a new keyword is needed. Pure means that the function itself does not make changes to data it does not own. We have a slight generalization because we allow the function to invoke closures that are given as arguments, so in fact a function declared as a pure is parametrically, or conditionally, pure---"as pure as the closures it is given as arguments".
@catamorphism is correct though that this is insufficiently strict for typestate. To be correct, typestate must prohibit reads from non-owned, mutable state. (Also, of course, for a type state predicate to be considered pure it is not enough that it calls a pure function, it must also not supply only pure closures as arguments)
catamorphism commentedon Jul 5, 2012
Two points from discussion on IRC: 1. It seems like "does not make changes to data it does not own" does amount to referentially transparent, as long as all higher-order function arguments are also referentially transparent (conditionally pure, as @nikomatsakis says). But this is fairly subtle and should be documented, or else people are going to look at a function and ask "how can this be pure, it mutates data?!" 2. The "conditionally pure" part is probably the most confusing thing. I'm not sure most people think "pure" means "as pure as its arguments". So I'm still in favor of changing the keyword.
catamorphism commentedon Nov 24, 2012
There doesn't seem to be much interest in changing the keyword, and now that we no longer have typestate we no longer have the motivating reason that there are two notions of purity. So I'm closing.
Auto merge of rust-lang#2753 - RalfJung:rustup, r=RalfJung
Merge pull request rust-lang#2753 from rust-lang/rustc-pull
Merge rust-lang#2753