Tutorial :F#: let mutable vs. ref



Question:

First, I acknowledge the possibility that this question could be a duplicate; just let me know.

I'm curious what the general "best practice" is for those situations when mutability is desired. F# seems to offer two facilities for this: the let mutable binding, which seems to work like variables in "most" languages, and the reference cell (created with the ref function) that requires explicit dereferencing to use.

There are a couple of cases where one is "forced" into one or the other: .NET interop tends to use mutable with <-, and in workflow computations one must use ref with :=. So those cases are pretty clear-cut, but I'm curious what to do when creating my own mutable variables outside of those scenarios. What advantage does one style have over the other? (Perhaps further insight into the implementation would help.)

Thanks!


Solution:1

I can only support what gradbot said - when I need mutation, I prefer let mutable.

Regarding the implementation and differences between the two - ref cells are essentially implemented by a very simple record that contains a mutable record field. You could write them easily yourself:

type ref<'T> =  // '    { mutable value : 'T } // '    // the ref function, ! and := operators look like this:  let (!) (a:ref<_>) = a.value  let (:=) (a:ref<_>) v = a.value <- v  let ref v = { value = v }  

A notable difference between the two approaches is that let mutable stores the mutable value on the stack (as a mutable variable in C#) while ref stores the mutable value in a field of a heap-allocated record. This may have some impact on the performance, but I don't have any numbers...

Thanks to this, mutable values that use ref can be aliased - meaning that you can create two values that reference the same mutable value:

let a = ref 5  // allocates a new record on the heap  let b = a      // b references the same record  b := 10        // modifies the value of 'a' as well!    let mutable a = 5 // mutable value on the stack  let mutable b = a // new mutable value initialized to current value of 'a'  b <- 10           // modifies the value of 'b' only!  


Solution:2

Related Question: "You mentioned that local mutable values cannot be captured by a closure, so you need to use ref instead. The reason for this is that mutable values captured in the closure need to be allocated on the heap (because closure is allocated on the heap)." from F# ref-mutable vars vs object fields

I think let mutable is preferred over reference cells. I personally only use reference cells when they are required.

Most code I write doesn't use mutable variables thanks to recursion and tail calls. If I have a group of mutable data I use a record. For objects I use let mutable to make private mutable variables. I only really use reference cells for closures, generally events.


Solution:3

As described in this MSDN Blog article in section Simplified use of mutable values, you no longer need ref cells for lambdas. So in general you no longer need them at all.


Solution:4

This article by Brian might provide an answer.

Mutables are easy to use and efficient (no wrapping), but can't be captured in lambdas. Ref cells can be captured, but are verbose and less efficient (? - not sure of this).


Solution:5

You may want to take a look at the Mutable Data section in the wikibook.

For convenience, here are some relevant quotes:

The mutable keyword is frequently used with record types to create mutable records

Mutable variables are somewhat limited: mutables are inaccessible outside of the scope of the function where they are defined. Specifically, this means its not possible to reference a mutable in a subfunction of another function.

Ref cells get around some of the limitations of mutables. In fact, ref cells are very simple data type which wrap up a mutable field in a record type.

Since ref cells are allocated on the heap, they can be shared across multiple functions


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »