A problem might arise when trying to prototype new ideas in an existing
codebase.
Suppose I have a sequence of pure operations f0,f1,f2,f3,f4 (note these
functions are only pure for the example below). Then both you and rust
would be aligned with the following code :
******************************
fn f0(x: &mut int) -> int { f1(x) }
fn f1(x: &mut int) -> int { f2(x) }
fn f2(x: &mut int) -> int { f3(x) }
fn f3(x: &mut int) -> int { f4(x) }
fn f4(x: &mut int) -> int { *x + 2 }
fn main() {
let mut x = ~1i;
let y = f0(x);
println!("{} {}", x, y);// 1 3
}
******************************
Then deep within my code if I wanted, as a test, to mutate a variable (such
a motivation is lacking for the code above, but just imagine), thus
breaking the purity of f0,f1,f2,f3,f4, then under your proposal we would
have to annotate the code with 5 new "mut" keywords as follows :
******************************
fn f0(x: &mut int) -> int { f1(mut x) }
fn f1(x: &mut int) -> int { f2(mut x) }
fn f2(x: &mut int) -> int { f3(mut x) }
fn f3(x: &mut int) -> int { f4(mut x) }
fn f4(x: &mut int) -> int { *x = 2; 3 }
fn main() {
let mut x = ~1i;
let y = f0(mut x);
println!("{} {}", x, y);// 2 3
}
******************************
Inserting all these new annotations simply for the purposes of testing out
a new idea might be quite cumbersome. If your rule was implemented, then
maybe having some sort of additional mechanism analogous to Haskell's
unsafeIO, to mask the mutation, would be useful :
http://www.haskell.org/haskellwiki/Avoiding_IO
"The method of last resort is unsafePerformIO. When you apply it, think
about how to reduce its use and how you can encapsulate it in a library
with a well chosen interface. Since unsafePerformIO makes functions look
like non-IO functions, they should also behave like non-IO functions. E.g.
file access must not be hidden in unsafePerformIO, whereas careful memory
manipulation may be safe – see for instance the Data.ByteString module."
However I do agree with you that it would be nice to have some annotation
in your reddit example.
On Wed, Apr 30, 2014 at 8:33 AM, Noam Yorav-Raphael <[email protected]>wrote:
> Hi,
>
> I had a bug caused by a function mutating its arguments, and it had
> occurred to me that it may be a good idea if rust would require a "mut"
> prefix in that case. I asked on reddit, and was referred to this thread:
> https://mail.mozilla.org/pipermail/rust-dev/2014-January/007670.html
>
> In the above message, Patrick shows a few examples which show that it's
> hard to come up with rules on which arguments should be prefixed by "mut"
> that will be sound and complete. I have an idea which may be. The idea is
> to not look at function arguments but at uses of a variable. Here's a rule:
>
> Whenever a variable which was declared with "let mut" is being used in a
> way that would have been illegal have it not been declared with "let mut",
> it should be prefixed by "mut", unless it's obvious from the context that
> it has to be mutable.
>
> I think it's quite simple and says exactly what should be the rules in
> Patrick's examples. What's not well-defined is the "obvious from the
> context" part. Certainly when a variable is on the left hand side of an
> assignment there would be no need for "mut" annotation, as well as when
> it's being prefixed by "&mut". I don't know if there are other cases.
>
> (If you're interested in the bug: I had to use a function solve(A, b)
> which gets a matrix A and a vector b and returns a vector x such that Ax=b.
> It does Gauss elimination, and for efficiency it modified A and b instead
> of allocating new arrays. I used it like x = solve(A, b) and then used A
> again. It was in Fortran, so the arguments A and b were annotated as being
> "in out", but of course it didn't stop my perfectly looking function from
> having a hidden bug.)
>
> What do you think?
> Noam
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
