On: John Carmack: Thoughts on Haskell [video]

[SilasX]

At the level of source code logic it appears to be copying and returning a new data structure. That doesn't mean the compiled, optimized code is performing all the copies that the the program appears to be doing.

Pure FP = don't mutate variables in the program. Of course the actual implementation can reuse memory blocks or else pure FPers would have to keep buying new memory!

[TylerE → SilasX]

Pure FP doesn't have variables. It has bindings.

[groovy2shoes → TylerE]

Function parameters are variables even in pure FP. If your definition of variable requires assignment, then even mathematics doesn't have variables.

[Aloisius → groovy2shoes]

Sure it does. The summation sigma has a variable right under it. Though they like to call it the index of summation, it is a variable with assignment.

[nightski → Aloisius]

Pretty sure summation definition is recursive. So no assignment/mutation is necessary.

[alipang → TylerE]

What do the bindings bind then?

So, no, even in pure functions like

    f x = x + 1

x is a bound variable. It doesn't 'vary' in the sense that the value it refers to can be mutated, as in a imperative language, but it varies between calls to the function f.

[TylerE → alipang]

It is rebound. It is improper to call it a "variable" because in any given lifetime, it's value cannot vary. That's the point. It is possible to create a new binding with the same name, but any code holding on to the old instance keeps the old value. Subtle but important difference.

[mbrock → TylerE]

You're simply wrong. That's not how the term "variable" works.

From http://en.wikipedia.org/wiki/Variable_(mathematics):

"Varying, in the context of mathematical variables, does not mean change in the course of time, but rather dependence on the context in which the variable is used."

[tel → mbrock]

While I agree with your philosophy of vocabulary here, I've read the Harper article too, it's valuable to state directly that everyone knows there's the _(Programming) article too and is simply disagreeing that its a "good" way to use the term. Anyone who isn't familiar with the distinction in terminology ought to consider what things a programming variable represents that a mathematics variable does not..

[Symmetry → mbrock]

From http://en.wikipedia.org/wiki/Variable_%28programming%29

"The identifier in computer source code can be bound to a value during run time, and the value of the variable may thus change during the course of program execution. Variables in programming may not directly correspond to the concept of variables in mathematics."

[mbrock → Symmetry]

It's wrong that it's "improper" to use the term "variable" for Haskell variables, since it is an established usage. This usage of "variable" occurs in the very first paragraph of Church's first paper on lambda calculus from 1931 in the motivation for the whole project!

[iopq → mbrock]

Math doesn't have vars, only vals

[mbrock → iopq]

That's a rather strange assertion, if you mean "variables" and "values." Math distinguishes between variables and values. Variables have different values. Values can be bound to variables. Sometimes we do math with mostly variables and few values -- that's called algebra.

[iopq → mbrock]

I mean Scala vars can be changed during the program, while Scala vals can't.

    val y = Console.readInt
    var x = y + 1
    x = y + 2 //valid
    y = 5 //error, vals can't be changed in the same block

[marssaxman → TylerE]

This seems like splitting hairs.

[kyllo → marssaxman]

When combined with lexically scoped closures, if you try to shadow your value bindings in a functional language and expect it to work the same way as mutating a variable does in an imperative language, you're in for a surprise.

[marssaxman → kyllo]

Sure, you have to restrict the scope in which rebinding is legal, but I don't see how it's fundamentally any different than the use of a phi-node in SSA form.

[kyllo → marssaxman]

Here's an SML example:

- val a = 1;

val a = 1 : int

- fun f() = a;

val f = fn : unit -> int

- f();

val it = 1 : int

- val a = 2;

val a = 2 : int

- f();

val it = 1 : int // a is still bound to 1 as far as f() is concerned

Now in Javascript:

> var a = 1;

undefined

> function f(){return a};

undefined

> f();

1

> a = 2;

2

> f();

2

>

If you bind a val, then you define a function that references that val, then you later shadow the val binding, then call the function again, the function still sees the earlier val binding, because it's a closure of the environment at the point where the function was defined, not at the point where it was called. This is unlike variable assignment in imperative languages.

[TylerE → marssaxman]

It's not. Referential transparency and immutability (or lack thereof) is a big deal, especially when it comes to multi-threaded code.