I am new to Haskell.
In Yet Another Haskell Tutorial, page Type Basics, I find this example:
count2 bTest list = foldr (\x cnt -> if bTest x then cnt+1 else cnt) 0 list
but I think that the lambda function
\x cnt -> if bTest x then cnt+1 else cnt
is not a pure function, given that its behavior depends on something external to the function, namely the function bTest. Is this correct?
Lambda abstractions are expressions which denote function values, much like arithmetic expressions denote numeric values. Both kinds of expressions might refer to variables defined elsewhere, and this does not break "purity"/referential transparency.
The value of the arithmetic expression
2*x + 1
depends on the value of x, but that does not make the above code "impure". Consider the function
f :: Int -> Int
f x = 2*x + 1
This produces the same output value for the same input value, so it it pure.
Now, consider the lambda expression
\y -> 2*x + y
This denotes a function value which depends on x, much like the arithmetic expression depends on x. There's no difference in this regard.
Indeed, the function
g :: Int -> (Int -> Int)
g x = \y -> 2*x + y
is pure: given the same x, it returns the same output value, which is a function. And, on top of that, the returned function is pure: given the same y, it returns the same numeric value. To stress the point
let h = g 5
in h 23 == h 23
evaluates to True since both h 23 evaluate to 2*5+23.
By comparison, this evaluates to False
let h1 = g 5
h2 = g 1
in h1 23 == h2 23
since we compare 2*5+23 against 2*1+23. This, however, does not break purity since h1 and h2 are different function values: we are not calling the same function with the same input, and that can indeed produce different results.
No this is not correct.
The lambda function returns the same output for the same input any time it is called, without any other effects.
To do that it does depend on the value of a parameter to the outer function, but that's just a detail.
In different invocations of count2 there might be used different values for bTest. In such situations the two lambda function will be different, yes, but the bTest values serve as a hidden implicit input. Still, the same inputs entailing the same output, which is the definition of "pure".
Related
So I have a function that returns a function. The returned function is supposed to return 0 for all inputs except x. For x it should return 10.
g x = do
let
f x = 10
f _ = 0
f
But instead the function always returns 10:
(g 3) 4
10
It seems that the parameter x is no the same x that gets used to create the function f. So how can I achieve that?
Your approach seems to be trying to use pattern matching like it's unification - Haskell doesn't perform unification, and pattern matching only works for things like data constructors (eg. Just), not for values.
The name x you're using in the inner definition shadows the name x used in the outer definition - so your inner function is equivalent to:
f x = 10
You should use a different variable name, and make your inner function compare its argument to the outer function's argument:
g x = let f y = if x == y then 10 else 0
in f
Or using currying, which is arguably better style:
g x y = if x == y then 10 else 0
This is semantically equivalent to the above version, and is also semantically equivalent to a function returning a lambda. We can partially apply g to a value to produce a function taking one parameter, eg:
> (g 3) 4
0
> (g "hi") "hi"
10
Pattern-matching "f X" compares argument with X only if X is a literal or data constructor (like "True"). When X is a variable it binds a new variable - in this case another "x" which shadows the outer one. You have to use good old comparison. For example, with guards:
f y | x == y = ...
f _ = ...
Haskell does not allow unification of variables that share the same name.
For example, f x x = ... is a syntax error rather than to say "match this case when the first and the second arguments are equal".
In your case, you have the same conceptual problem but no syntax error because Haskell simply shadows x from g once you try to match it using an argument in f. As matching a variable x without a constructor is unconditional it always succeeds and returns 10.
You want a function like this:
g x = \y -> if x == y then 10 else 0
which uses the (==) operator explicitly.
I want to calculate the "e" constant using Haskell's (Prelude) built-in until function. I want to do something like this:
enumber = until (>2.7) iter (1 0)
iter x k = x + (1/(fact (k + 1)))
fact k = foldr (*) 1 [1..k]
When I try to run this code, I get this error:
Occurs check: cannot construct the infinite type: a ~ a -> a
Expected type: (a -> a) -> a -> a
Actual type: a -> a -> a
Relevant bindings include enumber :: a -> a (bound at Lab2.hs:65:1)
In the second argument of ‘until’, namely ‘iter’
In the expression: until (> 2.7) iter (1 0)
By "e" I mean e = 2.71828..
The concrete mistake that causes this error is the notation (1 0). This doesn't make any sense in Haskell, it is parsed such that 1 is a function which is applied to 0, and the result then used. You apparently mean to pass both 1 and 0 as (initial) arguments. That's what we have tuples for, written (1,0).
Now, before trying to make anything definitions, we should make clear what types we need and write them out. Always start with your type signatures, they guide you a lot to you the actual definitions should look!
enumber :: Double -- could also be a polymorphic number type, but let's keep it simple.
type Index = Double -- this should, perhaps, actually be an integer, but again for simlicity use only `Double`
fact :: Index -> Double
now, if you want to do something like enumber = until (>2.7) iter (1,0), then iter would need to both add up the series expansion, and increment the k index (until knows nothing about indices), i.e. something like
iter :: (Double, Index) -> (Double, Index)
But right now your iter has a signature more like
iter :: Double -> Index -> Double
i.e. it does not do the index-incrementing. Also, it's curried, i.e. doesn't accept the arguments as a tuple.
Let's try to work with a tuple signature:
iter :: (Double, Index) -> (Double, Index)
iter (x,k) = ( x + 1/(fact (k + 1)), k+1 )
If you want to use this with until, you have the problem that you're always working with tuples, not just with the accumulated results. You need to throw away the index, both in the termination condition and in the final result: this can easily be done with the fst function
enumber = fst $ until ((>2.7) . fst) iter (1,0)
Now, while this version of the code will type-check, it's neither elegant nor efficient nor accurate (being greater than 2.7 is hardly a meaningful condition here...). As chi remarks, a good way of summing up stuff is the scanl function.
Apart from avoiding to manually increment and pass around an index, you should also avoid calculating the entire factorial over and over again. Doing that is a pretty general code smell (there's a reason fact isn't defined in the standard libraries)
recipFacts :: [Double] -- Infinite list of reciprocal factorials, starting from 1/0!
recipFacts = go 1
where go k = 1 : map (/k) (go (k+1))
Incidentally, this can also be written as a scan: scanl (/) 1 [1..] (courtesy of Will Ness).
Next we can use scanl to calculate the partial sums, and use some termination condition. However, because the series converges so quickly, there's actually a hack that works fine and is even simpler:
enumber :: Double
enumber = sum $ takeWhile (>0) recipFacts
-- result: 2.7182818284590455
Here I've used the fact that the fast-growing factorial quickly causes the floating-point reciprocals to underflow to zero.
Of course, really there's not a need to sum anything up yourself at all here: the most to-the-point definition is
enumber = exp 1
and nothing else.
enumber = until (>2.7) iter (1 0)
-- ^^^^^
Above you are applying "function" 1 to argument 0. This can't work.
You may want to use a pair instead (1, 0). In that case, not that iter must be changed to accept and return a pair. Also, the predicate >2.7 must be adapted to pairs.
If you don't want to use pairs, you need a different approach. Look up the scanl function, which you can use to compute partial sums. Then, you can use dropWhile to discard partial sums until some good-enough predicate is satisfied.
An example: the first ten partial sums of n^2.
> take 10 $ scanl (+) 0 [ n^2 | n<-[1..] ]
[0,1,5,14,30,55,91,140,204,285]
Note that this approach works only if you compute all the list elements independently. If you want to reuse some computed value from one element to another, you need something else. E.g.
> take 10 $ snd $ mapAccumL (\(s,p) x -> ((s+p,p*2),s+p)) (0,1) [1..]
[1,3,7,15,31,63,127,255,511,1023]
Dissected:
mapAccumL (\(s,p) x -> ((s+p,p*2),s+p)) (0,1) [1..]
a b c d e
s previous sum
p previous power of two
x current element of [1..]
a next sum
b next power of two
c element in the generated list
d first sum
e first power of two
Still, I am not a big fan of mapAccumL. Using iterate and pairs looks nicer.
y = [\a->a+3, \b->1 , \c->c*c]
I recognize function y has type of [Integer->Integer] , implies that it return list of function and each function takes integer then return a integer. However, I have trouble figure out the input of the function , could someone give me an example?
There isn't any input. y does not expect any parameter, it will only provides a list of function of type Integer -> Integer (or more precisely: Num a => a -> a).
How can it be useful?
Well, you can use it in many ways, some examples:
>>> let y = [\a->a+3, \b->1 , \c->c*c]
>>> map (\f -> f 3) y
[6,1,9]
>>> sequence y 4
[7,1,16]
>>> head y 10
13
First, the actual type of y is Num a => [a -> a], because integer numbers are polymorphic constants.
Second, y is not a function, it is a list. It does not take any arguments; its elements do. Or, if you want to call it a function, it has 0 arguments and returns a list.
y is not a function, it's a list of functions.
There is no input. It's just a list of functions. You can pick one of these functions up and call it with some input, but as it stands, it's just a bunch of functions that have been put into a list.
I am trying to understand currying by reading various blogs and stack over flow answers and I think I understood some what. In Haskell, every function is curried, it means, when you have a function like f x y = x + y
it really is ((f x) y)
in this, the function initially take the first parameter 'x' as the parameter and partially applies it to function f which in turn returns a function for y. where it takes just y a single parameter and applies the function. In both cases the function takes only one parameter and also the process of reducing a function to take single parameter is called 'currying'. Correct me if my understanding wrong here.
So if it is correct, could you please tell me if the functions 'two' and 'three' are curried functions?
three x y z = x + y + z
two = three 1
same = two 1
In this case, I have two specialized functions, 'two' and 'same' which are reduced to take only one parameter so is it curried?
Let's look at two first.
It has a signature of
two :: Num a => a -> a -> a
forget the Num a for now (it's only a constraint on a - you can read Int here).
Surely this too is a curried function.
The next one is more interesting:
same :: Num a => a -> a
(btw: nice name - it's the same but not exactly id ^^)
TBH: I don't know for sure.
The best definition I know of a curried function is this:
A curried function is a function of N arguments returning another function of (N-1) arguments.
(if you want you can extent this to fully curried functions of course)
This will only fit if you define constants as functions with 0 parameters - which you surely can.
So I would say yes(?) this too is a curried function but only in a mathy borderline way (like the sum of 0 numbers is defined to be 0)
Best just think about this equationally. The following are all equivalent definitions:
f x y z = x+y+z
f x y = \z -> x+y+z
f x = \y -> (\z -> x+y+z)
f = \x -> (\y -> (\z -> x+y+z))
Partial application is only tangentially relevant here. Most often you don't want the actual partial application to be performed and the actual lambda object to be created in memory - hoping instead that the compiler will employ - and optimize better - the full definition at the final point of full application.
The presence of the functions curry/uncurry is yet another confusing issue. Both f (x,y) = ... and f x y = ... are curried in Haskell, of course, but in our heads we tend to think about the first as a function of two arguments, so the functions translating between the two forms are named curry and uncurry, as a mnemonic.
You could think that three function with anonymous functions is:
three = \x -> (\y -> (\z -> x + y + z)))
This FAQ says that
The seq operator is
seq :: a -> b -> b
x seq y will evaluate x, enough to check that it is not bottom, then
discard the result and evaluate y. This might not seem useful, but it
means that x is guaranteed to be evaluated before y is considered.
That's awfully nice of Haskell, but does it mean that in
x `seq` f x
the cost of evaluating x will be paid twice ("discard the result")?
The seq function will discard the value of x, but since the value has been evaluated, all references to x are "updated" to no longer point to the unevaluated version of x, but to instead point to the evaluated version. So, even though seq evaluates and discards x, the value has been evaluated for other users of x as well, leading to no repeated evaluations.
No, it's not compute and forget, it's compute - which forces caching.
For example, consider this code:
let x = 1 + 1
in x + 1
Since Haskell is lazy, this evaluates to ((1 + 1) + 1). A thunk, containing the sum of a thunk and one, the inner thunk being one plus one.
Let's use javascript, a non-lazy language, to show what this looks like:
function(){
var x = function(){ return 1 + 1 };
return x() + 1;
}
Chaining together thunks like this can cause stack overflows, if done repeatedly, so seq to the rescue.
let x = 1 + 1
in x `seq` (x + 1)
I'm lying when I tell you this evaluates to (2 + 1), but that's almost true - it's just that the calculation of the 2 is forced to happen before the rest happens (but the 2 is still calculated lazily).
Going back to javascript:
function(){
var x = function(){ return 1 + 1 };
return (function(x){
return x + 1;
})( x() );
}
I believe x will only be evaluated once (and the result retained for future use, as is typical for lazy operations). That behavior is what makes seq useful.
You can always check with unsafePerformIO or trace…
import System.IO.Unsafe (unsafePerformIO)
main = print (x `seq` f (x + x))
where
f = (+4)
x = unsafePerformIO $ print "Batman!" >> return 3
Of course seq by itself does not "evaluate" anything. It just records the forcing order dependency. The forcing itself is triggered by pattern-matching. When seq x (f x) is forced, x will be forced first (memoizing the resulting value), and then f x will be forced. Haskell's lazy evaluation means it memoizes the results of forcing of expressions, so no repeat "evaluation" (scary quotes here) will be performed.
I put "evaluation" into scary quotes because it implies full evaluation. In the words of Haskell wikibook, "Haskell values are highly layered; 'evaluating' a Haskell value could mean evaluating down to any one of these layers."
Let me reiterate: seq by itself does not evaluate anything. seq x x does not evaluate x under any circumstance. seq x (f x) does not evaluate anything when f = id, contrary to what the report seems to have been saying.