I'm confused about how the where clause in Haskell works in a certain situation.
My biggest question is, is it possible to declare a variable that does something in the where clause and use back that declared variable through another variable declared in the where clause?
For example:
someFunc :: somefunc
.
| (guard expression)
| (guard expression)
where a = 1+3
b = a + 2 --using back 'a' variable which was also declared in the where clause.
Is this possible? When i do this haskell does not report any error but I was having doubts if it's a correct.
Yes. The variables in the where clause can see other variables in the same where clause.
For doubts, you can test it out with a simpler structure to see if it gives the correct value:
testing = b
where
a = 1000
b = a + 234
main = print testing
Does it print out 1234 as expected?
Yes, it is even possible to use the same variable in the expression as the one you define.
would work as well. In essence, the variables are just references to "expressions". So for your case you construct something that looks like:
┏━━━━━━━┓
b──>┃ (+) ┃
┣━━━┳━━━┫ ┏━━━┓
┃ o ┃ o─╂──>┃ 2 ┃
┗━┿━┻━━━┛ ┗━━━┛
│
v
┏━━━━━━━┓
a──>┃ (+) ┃
┣━━━┳━━━┫ ┏━━━┓
┃ o ┃ o─╂──>┃ 3 ┃
┗━┿━┻━━━┛ ┗━━━┛
│
│ ┏━━━┓
╰────────>┃ 1 ┃
┗━━━┛
This expression tree thus contains functions which point to other expression trees. Haskell will by default not evaluate these expressions: the expressions are evaluated lazily: only when you have to calculate these, you will calculate the corresponding value. Furthermore, if you are for example interested in the value of b, you thus will calculate the value of a, and thus the 1+3 expression will only be evaluated once. The same holds in the opposite direction: in case you first evaluate a, then evaluating b will benefit from the fact that a was already calculated. You can for example define two variables in terms of each other, like:
foo :: Int
foo = a
where a = 1 + b
b = 1 + a
but this will get stuck in an infinite loop since you will create an expression that looks like 1 + (1 + (1 + (...))).
We can even define a variable in terms of itself. For example the function below generates an infinite list of ones:
ones :: [Int]
ones = lst
where lst = 1 : lst
This will be represented as:
┏━━━━━━━┓
lst──>┃ (:) ┃<─╮
┣━━━┳━━━┫ │
┃ o ┃ o─╂──╯
┗━┿━┻━━━┛
│
v
┏━━━┓
┃ 1 ┃
┗━━━┛
calcProfit revenue cost= if revenue - cost >0
then revenue - cost
else 0
In this example we are repeating (revenuw-cost) your computation. This is a cheap operation but if it was an expensive operation you would be wasting resources. To prevent this, we use where clause:
calcProfit revenue cost = if profit >0
then profit
else 0
where profit= revenue-cost
With "where" clause we reverse the normal order used to write variables. In most of the programming languages, variables are declared before they’re used. In Haskell, because of referential transparency, variable order isn’t an issue.
As you see, we declare the variable "profit" in where clause and then we used it
Related
I have a computationally expensive vector I want to index into inside a function, but since the table is never used anywhere else, I don't want to pass the vector around, but access the precomputed values like a memoized function.
The idea is:
cachedFunction :: Int -> Int
cachedFunction ix = table ! ix
where table = <vector creation>
One aspect I've noticed is that all memoization examples I've seen deal with recursion, where even if a table is used to memoize, values in the table depend on other values in the table. This is not in my case, where computed values are found using a trial-and-error approach but each element is independent from another.
How do I achieve the cached table in the function?
You had it almost right. The problem is, your example basically scoped like this:
┌────────────────────────────────┐
cachedFunction ix = │ table ! ix │
│where table = <vector creation> │
└────────────────────────────────┘
i.e. table is not shared between different ix. This is regardless of the fact that it happens to not depend on ix (which is obvious in this example, but not in general). Therefore it would not be useful to keep it in memory, and Haskell doesn't do it.
But you can change that by pulling the ix argument into the result with its associated where-block:
cachedFunction = \ix -> table ! ix
where table = <vector creation>
i.e.
┌────────────────────────────────┐
cachedFunction = │ \ix -> table ! ix │
│where table = <vector creation> │
└────────────────────────────────┘
or shorter,
cachedFunction = (<vector creation> !)
In this form, cachedFunction is a constant applicative form, i.e. despite having a function type it is treated by the compiler as a constant value. It's not a value you could ever evaluate to normal form, but it will keep the same table around (which can't depend on ix; it doesn't have it in scope) when using it for evaluating the lambda function inside.
According to this answer, GHC will never recompute values declared at the top-level of a module. So by moving your table up to the top-level of your module, it will be evaluated lazily (once) the first time it's ever needed, and then it will never be requested again. We can see the behavior directly with Debug.Trace (example uses a simple integer rather than a vector, for simplicity)
import Debug.Trace
cachedFunction :: Int -> Int
cachedFunction ix = table + ix
table = traceShow "Computed" 0
main :: IO ()
main = do
print 0
print $ cachedFunction 1
print $ cachedFunction 2
Outputs:
0
"Computed"
1
2
We see that table is not computed until cachedFunction is called, and it's only computed once, even though we call cachedFunction twice.
This is my code
root::(Integer,Integer)->Integer
root guess number | (guess*guess == number ) =guess
| root (guess+number/guess)/2 number
main::IO()
main = {print(root 1,4)}
I keep getting parse error (possibly incorrect indentation or mismatched brackets) even if I don't mention the print statement inside braces. Can someone help me out?
First, you seem to have some confusion regarding declaring and passing parameters.
One can generally distinguish two ways (two "traditions" if you will) of passing parameters - "tupled form" and "curried form".
The former - "tupled form" - is passing all parameters together in a tuple:
-- Function declaration
root :: (Integer, Integer) -> Integer
root (guess, number) = ...
-- Calling the function
x = root (1, 4)
A tuple is denoted with parentheses and separating commas. Here, the type of parameters is a tuple - (Integer, Integer), - and the formal parameters are matched as a tuple - (guess, number), - and when calling the function I'm passing them as a tuple - (1, 4). Same syntax in all three cases.
Technically, this function has only one parameter, not two. And that one parameter is of tuple type.
The latter - "curried form" - is passing parameters "one by one", so to say:
-- Function declaration
root :: Integer -> Integer -> Integer
root guess number = ...
-- Calling the function
x = root 1 4
Here, the parameter types are declared separately in curried form - Integer -> Integer ->, - and the parameters are matched in a curried form - guess number = ..., - and when calling the function they are also passed in curried form - 1 4.
In your code, however, there seems to be a mishmash of these two styles:
The type of root says the parameters are tupled - (Integer, Integer)
The body of root says they are curried - root guess number
And the call site is sort of a half-tuple - there is a comma, but no parentheses.
Choose one style and follow it in all three places.
Second, the two cases in the body of root are malformed. Each case must have a form | <condition> = <body>. In your first case you have a condition (guess*guess == number) and a body guess, but in your second case there is only one part (there is no equality sign).
From the semantics, I would venture a guess that your second case was meant to be "otherwise" - i.e. it was meant to be evaluated if the first case's condition didn't match.
If that is correct, just add otherwise as condition:
| (guess*guess == number) = guess
| otherwise = root (guess+number/guess)/2 number
In a Codefights challenge where you have to add two numbers the user kaiochao had a super minimalisic answer
add = (+)
How does it work and has this functionality a own name?
Here's an explicit definition:
add a b = a + b
There is a feature in Haskell that says that we can rewrite a + b as (+) a b, this is due to the fact that operators are functions in Haskell. So we can rewrite:
add a b = (+) a b
But then we're doing nothing extra to the arguments of this function, so we can reduce this function by removing the explicit arguments*. Note that this requires an understanding of how function application in Haskell works:
add = (+)
This is because functions are data in Haskell. This is literally saying that plus and the function of addition are the same thing.
In practice, we can see this by substituting:
add 1 2
= (+) 1 2 -- Since add = (+), this can be read literally.
= 1 + 2 -- This is how operators work in Haskell.
= 3 -- Calculation.
This is known as pointfree style in Haskell.
*As #Benjamin Hodgson mentioned, this is called eta-reduction.
This “functionality” is just variable assignment. It works the same way as writing
three = 3
3 is just a Haskell value, which I can at any point give a new name, refer to it, and get something that's (at least, at runtime) indistinguishable from 3 itself.
The fact that add has a somewhat more complicated type, namely a function type, changes nothing about the way such variable assignments work. I can certainly define
root = sqrt
...and then evaluate root 4 to obtain 2.0 as the result. Or, for any custom function,
foo :: Int -> String
foo n = concat $ replicate n (show n)
bar = foo
GHCi> bar 3
"333"
GHCi> bar 7
"7777777"
All that is really no different from how I can also write
Python 3.5.2 (default, Sep 14 2017, 22:51:06)
Type 'copyright', 'credits' or 'license' for more information
IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import math
In [2]: root = math.sqrt
In [3]: root(4)
Out[3]: 2.0
What's a bit more interesting about add is that + is an infix operator (because it consists of non-letter characters). But Haskell allows using such infix operators pretty much just as liberally as any other variables, including that you can define your own. The only thing that's a bit different are the parsing rules. + can not be a standalone syntactic unit but has to be surrounded on each side with with arguments you want to add, or with parentheses. The latter, (+), is really what the plus operator is from the compiler's point of view: the binary function, not yet applied to any arguments. So, when you want to give this operator a new name, you need to write
add = (+)
Incidentally, you could also give it a new operator-name, like
(⊕) = (+)
...that could then be used like 3 ⊕ 4, just as you can with the standard + operator.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am learning a haskell for a few days and the laziness is something like buzzword. Because of the fact I am not familiar with laziness ( I have been working mainly with non-functional languages ) it is not easy concept for me.
So, I am asking for any excerise / example which show me what laziness is in the fact.
Thanks in advance ;)
In Haskell you can create an infinite list. For instance, all natural numbers:
[1,2..]
If Haskell loaded all the items in memory at once that wouldn't be possible. To do so you would need infinite memory.
Laziness allows you to get the numbers as you need them.
Here's something interesting: dynamic programming, the bane of every intro. algorithms student, becomes simple and natural when written in a lazy and functional language. Take the example of string edit distance. This is the problem of measuring how similar two DNA strands are or how many bytes changed between two releases of a binary executable or just how 'different' two strings are. The dynamic programming algorithm, expressed mathematically, is simple:
let:
• d_{i,j} be the edit distance of
the first string at index i, which has length m
and the second string at index j, which has length m
• let a_i be the i^th character of the first string
• let b_j be the j^th character of the second string
define:
d_{i,0} = i (0 <= i <= m)
d_{0,j} = j (0 <= j <= n)
d_{i,j} = d_{i - 1, j - 1} if a_i == b_j
d_{i,j} = min { if a_i != b_j
d_{i - 1, j} + 1 (delete)
d_{i, j - 1} + 1 (insert)
d_{i - 1, j - 1} + 1 (modify)
}
return d_{m, n}
And the algorithm, expressed in Haskell, follows the same shape of the algorithm:
distance a b = d m n
where (m, n) = (length a, length b)
a' = Array.listArray (1, m) a
b' = Array.listArray (1, n) b
d i 0 = i
d 0 j = j
d i j
| a' ! i == b' ! j = ds ! (i - 1, j - 1)
| otherwise = minimum [ ds ! (i - 1, j) + 1
, ds ! (i, j - 1) + 1
, ds ! (i - 1, j - 1) + 1
]
ds = Array.listArray bounds
[d i j | (i, j) <- Array.range bounds]
bounds = ((0, 0), (m, n))
In a strict language we wouldn't be able to define it so straightforwardly because the cells of the array would be strictly evaluated. In Haskell we're able to have the definition of each cell reference the definitions of other cells because Haskell is lazy – the definitions are only evaluated at the very end when d m n asks the array for the value of the last cell. A lazy language lets us set up a graph of standing dominoes; it's only when we ask for a value that we need to compute the value, which topples the first domino, which topples all the other dominoes. (In a strict language, we would have to set up an array of closures, doing the work that the Haskell compiler does for us automatically. It's easy to transform implementations between strict and lazy languages; it's all a matter of which language expresses which idea better.)
The blog post does a much better job of explaining all this.
So, I am asking for any excerise / example which show me what laziness is in the fact.
Click on Lazy on haskell.org to get the canonical example. There are many other examples just like it to illustrate the concept of delayed evaluation that benefits from not executing some parts of the program logic. Lazy is certainly not slow, but the opposite of eager evaluation common to most imperative programming languages.
Laziness is a consequence of non-strict function evaluation. Consider the "infinite" list of 1s:
ones = 1:ones
At the time of definition, the (:) function isn't evaluated; ones is just a promise to do so when it is necessary. Such a time would be when you pattern match:
myHead :: [a] -> a
myHead (x:rest) = x
When myHead ones is called, x and rest are needed, but the pattern match against 1:ones simply binds x to 1 and rest to ones; we don't need evaluate ones any further at this time, so we don't.
The syntax for infinite lists, using the .. "operator" for arithmetic sequences, is sugar for calls to enumFrom and enumFromThen. That is
-- An infintite list of ones
ones = [1,1..] -- enumFromThen 1 1
-- The natural numbers
nats = [1..] -- enumFrom 1
so again, laziness just comes from the non-strict evaluation of enumFrom.
Unlike with other languages, Haskell decouples the creation and definition of an object.... You can easily watch this in action using Debug.Trace.
You can define a variable like this
aValue = 100
(the value on the right hand side could include a complicated evaluation, but let's keep it simple)
To see if this code ever gets called, you can wrap the expression in Debug.Trace.trace like this
import Debug.Trace
aValue = trace "evaluating aValue" 100
Note that this doesn't change the definition of aValue, it just forces the program to output "evaluating aValue" whenever this expression is actually created at runtime.
(Also note that trace is considered unsafe for production code, and should only be used to debug).
Now, try two experiments.... Write two different mains
main = putStrLn $ "The value of aValue is " ++ show aValue
and
main = putStrLn "'sup"
When run, you will see that the first program actually creates aValue (you will see the "creating aValue" message, while the second does not.
This is the idea of laziness.... You can put as many definitions in a program as you want, but only those that are used will be actually created at runtime.
The real use of this can be seen with objects of infinite size. Many lists, trees, etc. have an infinite number of elements. Your program will use only some finite number of values, but you don't want to muddy the definition of the object with this messy fact. Take for instance the infinite lists given in other answers here....
[1..] -- = [1,2,3,4,....]
You can again see laziness in action here using trace, although you will have to write out a variant of [1..] in an expanded form to do this.
f::Int->[Int]
f x = trace ("creating " ++ show x) (x:f (x+1)) --remember, the trace part doesn't change the expression, it is just used for debugging
Now you will see that only the elements you use are created.
main = putStrLn $ "the list is " ++ show (take 4 $ f 1)
yields
creating 1
creating 2
creating 3
creating 4
the list is [1,2,3,4]
and
main = putStrLn "yo"
will not show any item being created.
I'm trying to write a function in Haskell that calculates all factors of a given number except itself.
The result should look something like this:
factorlist 15 => [1,3,5]
I'm new to Haskell and the whole recursion subject, which I'm pretty sure I'm suppoused to apply in this example but I don't know where or how.
My idea was to compare the given number with the first element of a list from 1 to n div2
with the mod function but somehow recursively and if the result is 0 then I add the number on a new list. (I hope this make sense)
I would appreciate any help on this matter
Here is my code until now: (it doesn't work.. but somehow to illustrate my idea)
factorList :: Int -> [Int]
factorList n |n `mod` head [1..n`div`2] == 0 = x:[]
There are several ways to handle this. But first of all, lets write a small little helper:
isFactorOf :: Integral a => a -> a -> Bool
isFactorOf x n = n `mod` x == 0
That way we can write 12 `isFactorOf` 24 and get either True or False. For the recursive part, lets assume that we use a function with two arguments: one being the number we want to factorize, the second the factor, which we're currently testing. We're only testing factors lesser or equal to n `div` 2, and this leads to:
createList n f | f <= n `div` 2 = if f `isFactorOf` n
then f : next
else next
| otherwise = []
where next = createList n (f + 1)
So if the second parameter is a factor of n, we add it onto the list and proceed, otherwise we just proceed. We do this only as long as f <= n `div` 2. Now in order to create factorList, we can simply use createList with a sufficient second parameter:
factorList n = createList n 1
The recursion is hidden in createList. As such, createList is a worker, and you could hide it in a where inside of factorList.
Note that one could easily define factorList with filter or list comprehensions:
factorList' n = filter (`isFactorOf` n) [1 .. n `div` 2]
factorList'' n = [ x | x <- [1 .. n`div` 2], x `isFactorOf` n]
But in this case you wouldn't have written the recursion yourself.
Further exercises:
Try to implement the filter function yourself.
Create another function, which returns only prime factors. You can either use your previous result and write a prime filter, or write a recursive function which generates them directly (latter is faster).
#Zeta's answer is interesting. But if you're new to Haskell like I am, you may want a "simple" answer to start with. (Just to get the basic recursion pattern...and to understand the indenting, and things like that.)
I'm not going to divide anything by 2 and I will include the number itself. So factorlist 15 => [1,3,5,15] in my example:
factorList :: Int -> [Int]
factorList value = factorsGreaterOrEqual 1
where
factorsGreaterOrEqual test
| (test == value) = [value]
| (value `mod` test == 0) = test : restOfFactors
| otherwise = restOfFactors
where restOfFactors = factorsGreaterOrEqual (test + 1)
The first line is the type signature, which you already knew about. The type signature doesn't have to live right next to the list of pattern definitions for a function, (though the patterns themselves need to be all together on sequential lines).
Then factorList is defined in terms of a helper function. This helper function is defined in a where clause...that means it is local and has access to the value parameter. Were we to define factorsGreaterOrEqual globally, then it would need two parameters as value would not be in scope, e.g.
factorsGreaterOrEqual 4 15 => [5,15]
You might argue that factorsGreaterOrEqual is a useful function in its own right. Maybe it is, maybe it isn't. But in this case we're going to say it isn't of general use besides to help us define factorList...so using the where clause and picking up value implicitly is cleaner.
The indentation rules of Haskell are (to my tastes) weird, but here they are summarized. I'm indenting with two spaces here because it grows too far right if you use 4.
Having a list of boolean tests with that pipe character in front are called "guards" in Haskell. I simply establish the terminal condition as being when the test hits the value; so factorsGreaterOrEqual N = [N] if we were doing a call to factorList N. Then we decide whether to concatenate the test number into the list by whether dividing the value by it has no remainder. (otherwise is a Haskell keyword, kind of like default in C-like switch statements for the fall-through case)
Showing another level of nesting and another implicit parameter demonstration, I added a where clause to locally define a function called restOfFactors. There is no need to pass test as a parameter to restOfFactors because it lives "in the scope" of factorsGreaterOrEqual...and as that lives in the scope of factorList then value is available as well.