I would have thought that the shadowed version would be overwritten or removed. Is there any way to access the shadowed version? Is there any good reason to let programmers shadow values in this way?

The "#light" syntax allows one to drop some language syntax in favor of indenting, which in this case may obscure what is actually being defined. Perhaps the symantically identical "regular syntax" version will shed some light (pun intended); note that indentation is not significant in the following:

1
2
3
4
5

let a() = 
    let foo = [1] in
        printfn "%A" foo;
        let foo = [1;2] in
            printfn "%A" foo

Each "let ... in ..." binding above in effect opens up a new scope. The second foo label shadows the first foo label. I don't know if that means [1] can now be garbage collected, but there are logically two values in memory now foo=[1] and foo=[1;2]. This differs from mutable assignment, where [1] would be replaced by [1;2].

To prove the point, run the following code. Note that b() produces different results for each foo value, showing that both are independent of each other, whereas c() produces the same result for the values, because the original memory location (the reference cell called foo) was overwritten.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

> let b() =
    let foo = [1] in
    let out_foo_1() = printfn "foo_1 = %A" foo in
    let foo = [1;2] in
    let out_foo_2() = printfn "foo_2 = %A" foo in
    do out_foo_1();
    do out_foo_2()
 
let c() =
    let foo = ref [1] in
    let out_foo_1() = printfn "foo_1 = %A" !foo in
    do foo := [1;2];
    let out_foo_2() = printfn "foo_2 = %A" !foo in
    do out_foo_1();
    do out_foo_2();;

val b : unit -> unit
val c : unit -> unit

> b();;
foo_1 = [1]
foo_2 = [1; 2]
val it : unit = ()

> c();;
foo_1 = [1; 2]
foo_2 = [1; 2]
val it : unit = ()
>

Think of "let" as declaring a constant, and you won't be far off. To get a "variable" you must say either "let mutable foo = x" or, when using the value in a closure like out_foo_x above, you must use a reference cell, in which case the let binding declares a constant reference to a cell, and the cell is the thing that can change. In fact, ref could be (is?) defined as:

1

type 'a ref = { mutable contents : 'a; }

They don't really have the same scope. A "let ... in expr" expression opens a new scope for expr. It's like if you use { } is some other languages.

By the way, it's sometimes useful to shadow values. I often write "let foo = defaultArg foo 0" when I use optional arguments.

You can't access shadowed values. You first need to close the inner scope if you want to use the outer value.

Laurent.

Mike,

Then the beginner types...

1
2
3
4
5

let a() = 
    let foo = [1]
    printfn "%A" foo
    let foo = [1;2]
    printfn "%A" foo

...in a regular code file and asks the same question.

I didn't think about doing it in a function as I don't see any good reason for doing that. I thought that once it is defined in a particular scope that that is it. Interesting but again I don't see any reason as to why one would do this in the first place.

And then you explain that they are in fact different foo's, and the beginner is not altering them. The second 'let' indicates this. It's not:

1
2
3
4
5
6
7
8
9
10

let a() = 

    let foo = [1]

    printfn "%A" foo

    foo = [1;2]

    printfn "%A" foo

And the same goes for F# interactive: you're not mutating, you're defining a new variable which just happens to have the same name as the previous one.

It seems to me that you should be able to explain this to a beginner. I do agree that the behavior from the code block above can be confusing at first - although I use it sometimes myself to do a long calculation in steps without having to invent new nonsensical names for all the intermediaries.

Kurt