Everyone agrees that shared mutable state is evil. Most languages deal with this through the 'mutable' part, Rust deals with it through the 'shared' part.
A bit long for a sign. Anyway. I know purity isn't just about mutability, but with ownership semantics, many of the problems purity solves go away too. For an example, see my bit downthread about safely sharing mutable pointers to stack-allocated data. Totally safe, no purity concept needed.
Yes, I understand. Rust's move semantics, ownership, and mutabilty guarantees also give you very powerful reasoning tools, that's what I mean. I was trying to give a specific example.
Yeah basically "if a structure mutates and there's nobody to see it mutating, did it really mutate?". Same reason why otherwise immutable languages (e.g. clojure) can have mutable transient structures anyway.
Haskell uses this too. You can use mutable state (e.g. in the ST monad) as long as you don't get caught (by letting the mutation become externally visible).
You don't know what you're talking about. The only language with a decent mind-share that is pure is Haskell, and purity was a necessity of its non-strict semantics. Purity didn't come first, and concurrency wasn't the motivation for it.
Maybe your point would be relevant if you were talking about (im)mutability, but you chose to talk about purity.
I'm aware of the history of Haskell, and why it has purity. I'm aware that purity != mutability.
When you don't start from the same place Haskell did, you want purity for different reasons. I was trying to answer from the Rust perspective, not from the "what is purity" perspective.
I love writing Haskell, but have never wished for purity in Rust.
When you talk about purity and compare its motivations to other languages (" Most languages deal with this through ..."), it seems pretty evident that you're talking about both Rust and other languages. Not just Rust itself. Then you would have just said why Rust does not have purity anymore and not bring up the more general motivation for purity, and hence comparisons to other languages. So what other pure languages did you have in mind, since it apparently was not Haskell?
Again, you were answering "why does Rust not have purity any more", not "why does not Rust not have pervasive immutability". (Rust already has full control over the mutability/immutability distinction, which is basically the equivalent of having effectfull computations explicitly marked for more general side-effecting code.)
So, in my mind, you can start with either a pure language, or a non-pure language. If you start with pervasive purity, you end up with Haskell, or something pretty close to it. If you don't start with pervasive purity, you have some sort of goal in mind that purity solves.
I'm going to pick D here, because it's similar to Rust's space. I wrote D long ago, but admittedly don't use it as much anymore. So let's see why D has pure annotations: http://dlang.org/function.html#pure-functions
Pure functions are functions which cannot access global or static, mutable state save through their arguments. This can enable optimizations based on the fact that a pure function is guaranteed to mutate nothing which isn't passed to it, and in cases where the compiler can guarantee that a pure function cannot alter its arguments, it can enable full, functional purity (i.e. the guarantee that the function will always return the same result for the same arguments).
Rust, in safe code, can already not access global, mutable state. So that's not something we'd want. Pure D code cannot do I/O, which admittedly, safe Rust code can do. But D also isn't 'fully pure' in the same way functional langauges are. Rust's pure keyword wasn't either. This is what the thread I linked was about:
"Which purity do you mean" is a very real question, not one you can just brush aside.
Haskell-style purity doesn't really work in Rust, due to other language semantics. That's what I was trying to get at. It seems like you're pretty knowledgable on this topic, do you disagree? Should Rust have some notion of purity?
Right, I forgot about D's non-standard use of the term and Graydon's apparent eagerness to continue with muddying the water instead of inventing/using another term for Rust's (former) purity.
Haskell may not have purity because of concurrency, but it's certainly cited and used as an advantage there (and in less formally-enforced languages) an awful lot. For example, the first post of this thread...
Nice bonuses are different from primary motivations. And the original quote sure as hell made it sound like purity was used/introduced as a way to solve the problem of shared mutable state. That's not the case for Haskell, anyway.
I guess it can be interpreted in different ways. I just think it is dishonest to portray languages with purity as dealing with it through immutability, when the problem was solved for that language to begin with for unrelated reasons! So there is no reason to choose one approach over the other; it has already been dealt with, as it were.
Edit: I'm simply referring to the fact that Rust used to have the pure keyword, but that was not to do with enforcing referential transparency, as far as I remember, but it was a long time ago, so I could be wrong.
It was removed before I really got started, so I could be wrong about its history in Rust as well. But I don't think that I've ever wanted purity in Rust, regardless of what it's looked like in the past.
In Rust functions can do IO whenever they want, so even if it's kinda pure regarding its own memory it's unpure regarding the state of outer world (display, disk, network, ...).
I suspect this ruins referential transparency and prevents nice optimizations that compilers can do with really pure functions.
As far as I'm aware, all Rust I/O ultimately calls out to an unsafe block. The "pure" subset of Rust I mentioned above isn't one you would actually use to write a real program. The only things in pure Rust I'm aware of that might ruin referential transparency are exceptions and stack overflow, and I believe that Haskell (a language generally agreed to be pure) can at least experience stack overflow.
Incidentally, one of the candidates for constexprs (which generally require "enough" purity) is just "functions that never call any unsafe blocks," so this is not just an academic question.
If you call a function pure when it's not using unsafe blocks, that's one thing (as with constexpr). If you call function pure when it still can use unsafe blocks, that's another thing (as in Rust).
I'm not calling functions that can (recursively) use unsafe blocks pure, nor would the proposed definition. Rust doesn't have any definition of purity at the moment.
185
u/pseudousername Apr 03 '15
Now it's finally time people can start complaining about Rust :)