Due to how scoping and how do-comprehensions actually work, you can do some things that look like assignment, but are really creating a new binding in a nested scope. But if you try to bind a name twice in the same scope, the program fails to compile.
But I thought this page was interesting:
http://www.haskell.org/haskellwiki/Pronunciation
'=' is pronounced as 'is'.
So you'd say something like 'main is the function that evaluates the expression...' Traditional assignment would be something more like 'the value stored in the container main now becomes the expression...'
Keep in mind that there are at least three popular definitions of the = operator:
1. In C or C++, = handles assignment and mutation (no re-assignment):
int x = 1; /* assignment */
x = 2; /* mutation */
x = [1] # assignment
x = [2] # re-assignment
let x = 1 in
To me, the statement "programming without assignment" implies programming without making multiple assignments to the same name - mutation or re-assignment. I don't know if the programming language community has agreed-upon semantics for the word "assignment," but to me, it implies re-assignment and mutation. What you call "assignment" I think of as binding - that is, the lvalue gets bound to the rvalue.
From a pedantic perspective, you can't really disagree with the statement 'haskell supports single assignment.' But equally as pedantic, most actual text reads 'FP doesn't support variable assignment', including the original article above.
I don't have a copy of the Ravi Sethi book to see what the exact text of his exact statement was.
Now that I've seen this image on wikipedia:
https://secure.wikimedia.org/wikipedia/en/wiki/File:Fp_no_de...
I'm really tempted to waste some more money at Cafe Press.
main=print n
n=42
x = 0:y
y = 1:x
main = print $ take 10 y
[1,0,1,0,1,0,1,0,1,0]
1. Is not magic problem-solving pixie dust (obviously).
2. Is not a philosophy, mindset-altering or otherwise.
3. Is a novel theory of computation.
Whether a Turing machine and the lambda calculus are equivalent in power is irrelevant; they are, undeniably, different. Otherwise, there would be no point in using one over the other.
This entire section deals with Perl, which is not a functional language (as it is not based on the lambda calculus). I don't know enough about Perl to state whether the authors assertions are correct, but regardless, they have nothing to do with functional programming.The second half of section #3 claims referential transparency is impossible because it requires two values with some external equivalent meaning, such as "three" and "3", to be considered equivalent by the program. At this point I'm wondering whether the entire article is some elaborate prank.
Section #4 is already off to a bad start...in fact, reading further, it's just more of the same. Abject confusion, combined with a belief that Perl can be used to demonstrate functional concepts, yielding incomprehensible conclusions.