Re: [Haskell-cafe] Assignment, Substitution or what?
f x = x + x Is the "x" use to create a pattern in the definition and when f is called it's replaced by a value?
Those equation-like definitions are syntactic sugar for lambda abstractions. f could as well be defined as f = \x -> x + x.
Please elaborate
First, the
f x =
part says that f is a function which takes a single parameter, called x. The other side of the = sign gives the function body: in this case, x + x. This is exactly the same thing that is expressed by the lambda expression
\x -> x + x
This expression defines a function that takes a single parameter called x, and returns the value of x + x. The only difference is that with the lambda expression, this function is not given a name. But you can easily give the function a name (just as you can give any Haskell expression a name) by writing
f = \x -> x + x
In general, writing
g x y z = blah blah
is just a shorthand for
g = \x -> \y -> \z -> blah blah.
That is, it simultaneously creates a function expression, and assigns it a name.
Does that help?
Yes and thanks for the reply. When a function is declared in C the argument variable has an address somewhere in the memory: int f ( int x ) { return x * x; } any value passed to f() is assigned to x. x is the identifier for a real slot in the memory (the stack most likely) made available for f(). Is this also what happens in Haskell? Thanks, Paul
On Wed, 2007-10-03 at 01:42 +0100, PR Stanley wrote:
f x = x + x Is the "x" use to create a pattern in the definition and when f is called it's replaced by a value?
Those equation-like definitions are syntactic sugar for lambda abstractions. f could as well be defined as f = \x -> x + x.
Please elaborate
First, the
f x =
part says that f is a function which takes a single parameter, called x. The other side of the = sign gives the function body: in this case, x + x. This is exactly the same thing that is expressed by the lambda expression
\x -> x + x
This expression defines a function that takes a single parameter called x, and returns the value of x + x. The only difference is that with the lambda expression, this function is not given a name. But you can easily give the function a name (just as you can give any Haskell expression a name) by writing
f = \x -> x + x
In general, writing
g x y z = blah blah
is just a shorthand for
g = \x -> \y -> \z -> blah blah.
That is, it simultaneously creates a function expression, and assigns it a name.
Does that help?
Yes and thanks for the reply. When a function is declared in C the argument variable has an address somewhere in the memory: int f ( int x ) { return x * x; }
any value passed to f() is assigned to x. x is the identifier for a real slot in the memory (the stack most likely) made available for f(). Is this also what happens in Haskell?
How would you tell?
On 3 Oct 2007, at 1:42 pm, PR Stanley wrote:
When a function is declared in C the argument variable has an address somewhere in the memory: int f ( int x ) { return x * x; }
Wrong. On the machines I use, x will be passed in registers and will never ever have an address in memory. In fact, unless I hold the Sun C compiler back by main force, it will probably open code f() so that there isn't any f any more, let alone any x. Here's the actual SPARC code generated for f: f: retl mulx %o0,%o0,%o0 No memory, no address. In C, a function call is rather like entering a new block, declaring some new variables (which might or might not ever go into memory) and initialising them to the values of the arguments. In Haskell, carrying out a function call is rather like creating some new names and *binding* them to promises to evaluate the arguments (if they are ever needed) and then returning a promise to evaluate the body (if it is ever needed). The key point is *binding* names to (deferred calculations of) values, rather than *initialising* mutable variables to (fully evaluated) values. How this is done is entirely up to the compiler.
PR Stanley wrote:
Yes and thanks for the reply. When a function is declared in C the argument variable has an address somewhere in the memory: int f ( int x ) { return x * x; }
any value passed to f() is assigned to x. x is the identifier for a real slot in the memory (the stack most likely) made available for f(). Is this also what happens in Haskell?
It is not, in my opinion, an unreasonable intuition. What's interesting to note is that because haskell values are immutable, there is no need for this to be a *new* memory location. In fact, in a typical simple haskell implementation what f is actually passed is a pointer to to the existing memory location. Procedure call in haskell doesn't normally involve argument copying, because with immutability there is no need for copying. Of course 'x*x' is a new value, so new memory is definitely allocated for that. The next epiphany of understanding is when you realise that what actually goes into that new memory is a code pointer, rather than a value. Instead of calculating 'x*x' the compiler simply chucks a pointer to the code which, when called, will calculate x*x. This code is only called if needed. Jules
participants (4)
-
Derek Elkins -
Jules Bean -
ok -
PR Stanley