# Let vs. Where

### From HaskellWiki

(Difference between revisions)

(let is an expression) |
(Improved lay-out) |
||

(10 intermediate revisions by 7 users not shown) | |||

Line 1: | Line 1: | ||

− | Haskell programmers often wonder | + | Haskell programmers often wonder whether to use <hask>let</hask> or <hask>where</hask>. |

− | This seems to be only a matter of taste in the sense of "[[Declaration vs. | + | This seems to be only a matter of taste in the sense of "[[Declaration vs. expression style]]", however there is more to it. |

− | however there is more | + | |

− | It is important to know that <hask>let ... in ...</hask> is an expression, | + | It is important to know that <hask>let ... in ...</hask> is an expression, that is, it can be written wherever expressions are allowed. In contrast, <hask>where</hask> is bound to a surrounding syntactic construct, like the [[pattern matching]] line of a function definition. |

− | that is, it can be written | + | |

− | In contrast | + | |

− | like the [[pattern matching]] line of a function definition. | + | |

− | + | == Advantages of let == | |

+ | |||

+ | Suppose you have the function | ||

<haskell> | <haskell> | ||

f :: s -> (a,s) | f :: s -> (a,s) | ||

Line 39: | Line 37: | ||

</haskell> | </haskell> | ||

+ | == Advantages of where == | ||

+ | |||

+ | Because "where" blocks are bound to a syntactic construct, they can be used to share bindings between parts of a function that are not syntactically expressions. For example: | ||

+ | |||

+ | <haskell> | ||

+ | f x | ||

+ | | cond1 x = a | ||

+ | | cond2 x = g a | ||

+ | | otherwise = f (h x a) | ||

+ | where | ||

+ | a = w x | ||

+ | </haskell> | ||

+ | |||

+ | In expression style, you might use an explicit <hask>case</hask>: | ||

+ | |||

+ | <haskell> | ||

+ | f x | ||

+ | = let a = w x | ||

+ | in case () of | ||

+ | _ | cond1 x -> a | ||

+ | | cond2 x -> g a | ||

+ | | otherwise -> f (h x a) | ||

+ | </haskell> | ||

+ | |||

+ | or a [[Case|functional equivalent]]: | ||

+ | |||

+ | <haskell> | ||

+ | f x = | ||

+ | let a = w x | ||

+ | in select (f (h x a)) | ||

+ | [(cond1 x, a), | ||

+ | (cond2 x, g a)] | ||

+ | </haskell> | ||

+ | |||

+ | or a series of if-then-else expressions: | ||

+ | |||

+ | <haskell> | ||

+ | f x | ||

+ | = let a = w x | ||

+ | in if cond1 x | ||

+ | then a | ||

+ | else if cond2 x | ||

+ | then g a | ||

+ | else f (h x a) | ||

+ | </haskell> | ||

+ | |||

+ | These alternatives are arguably less readable and hide the structure of the function more than simply using <hask>where</hask>. | ||

+ | |||

+ | == Lambda Lifting == | ||

+ | |||

+ | One other approach to consider is that let or where can often be implemented using [[lambda lifting]] and [[let floating]], incurring at least the cost of introducing a new name. The above example: | ||

+ | |||

+ | <haskell> | ||

+ | f x | ||

+ | | cond1 x = a | ||

+ | | cond2 x = g a | ||

+ | | otherwise = f (h x a) | ||

+ | where | ||

+ | a = w x | ||

+ | </haskell> | ||

+ | |||

+ | could be implemented as: | ||

+ | |||

+ | <haskell> | ||

+ | f x = f' (w x) x | ||

+ | |||

+ | f' a x | ||

+ | | cond1 x = a | ||

+ | | cond2 x = g a | ||

+ | | otherwise = f (h x a) | ||

+ | </haskell> | ||

+ | |||

+ | The auxiliary definition can either be a top-level binding, or included in f using <hask>let</hask> or <hask>where</hask>. | ||

+ | |||

+ | == Problems with where == | ||

+ | |||

+ | If you run both | ||

+ | <haskell> | ||

+ | fib = (map fib' [0 ..] !!) | ||

+ | where | ||

+ | fib' 0 = 0 | ||

+ | fib' 1 = 1 | ||

+ | fib' n = fib (n - 1) + fib (n - 2) | ||

+ | </haskell> | ||

+ | and | ||

+ | <haskell> | ||

+ | fib x = map fib' [0 ..] !! x | ||

+ | where | ||

+ | fib' 0 = 0 | ||

+ | fib' 1 = 1 | ||

+ | fib' n = fib (n - 1) + fib (n - 2) | ||

+ | </haskell> | ||

+ | you will notice, that the second one runs considerably slower than the first one. You may wonder, why just adding the explicit argument to <hask>fib</hask> (known as [[eta expansion]]) reduces the performance dramatically. | ||

+ | |||

+ | You might see the reason better, if you rewrite this code using <hask>let</hask>. | ||

+ | Compare | ||

+ | <haskell> | ||

+ | fib = | ||

+ | let fib' 0 = 0 | ||

+ | fib' 1 = 1 | ||

+ | fib' n = fib (n - 1) + fib (n - 2) | ||

+ | in (map fib' [0 ..] !!) | ||

+ | </haskell> | ||

+ | and | ||

+ | <haskell> | ||

+ | fib x = | ||

+ | let fib' 0 = 0 | ||

+ | fib' 1 = 1 | ||

+ | fib' n = fib (n - 1) + fib (n - 2) | ||

+ | in map fib' [0 ..] !! x | ||

+ | </haskell> | ||

+ | . In the second case <hask>fib'</hask> is (re-)defined for every argument <hask>x</hask>, thus it cannot be floated out.<br><br> | ||

+ | |||

+ | In contrast to that, in the first case <hask>fib'</hask> can be moved to the top level by a compiler. | ||

+ | The <hask>where</hask> clause hid this structure | ||

+ | and made the application to <hask>x</hask> look like a plain eta expansion, which it is not. | ||

+ | * Haskell-Cafe on [http://www.haskell.org/pipermail/haskell-cafe/2010-October/084538.html Eta-expansion destroys memoization?] | ||

[[Category:Style]] | [[Category:Style]] | ||

[[Category:Syntax]] | [[Category:Syntax]] |

## Revision as of 06:11, 24 October 2012

Haskell programmers often wonder whether to uselet

where

This seems to be only a matter of taste in the sense of "Declaration vs. expression style", however there is more to it.

It is important to know thatlet ... in ...

where

## Contents |

## 1 Advantages of let

Suppose you have the function

f :: s -> (a,s) f x = y where y = ... x ...

Control.Monad.State

However, transforming to

f :: State s a f = State $ \x -> y where y = ... x ...

where

f =

x

let

f :: s -> (a,s) f x = let y = ... x ... in y

This is easily transformed to:

f :: State s a f = State $ \x -> let y = ... x ... in y

## 2 Advantages of where

Because "where" blocks are bound to a syntactic construct, they can be used to share bindings between parts of a function that are not syntactically expressions. For example:

f x | cond1 x = a | cond2 x = g a | otherwise = f (h x a) where a = w x

case

f x = let a = w x in case () of _ | cond1 x -> a | cond2 x -> g a | otherwise -> f (h x a)

or a functional equivalent:

f x = let a = w x in select (f (h x a)) [(cond1 x, a), (cond2 x, g a)]

or a series of if-then-else expressions:

f x = let a = w x in if cond1 x then a else if cond2 x then g a else f (h x a)

where

## 3 Lambda Lifting

One other approach to consider is that let or where can often be implemented using lambda lifting and let floating, incurring at least the cost of introducing a new name. The above example:

f x | cond1 x = a | cond2 x = g a | otherwise = f (h x a) where a = w x

could be implemented as:

f x = f' (w x) x f' a x | cond1 x = a | cond2 x = g a | otherwise = f (h x a)

let

where

## 4 Problems with where

If you run both

fib = (map fib' [0 ..] !!) where fib' 0 = 0 fib' 1 = 1 fib' n = fib (n - 1) + fib (n - 2)

and

fib x = map fib' [0 ..] !! x where fib' 0 = 0 fib' 1 = 1 fib' n = fib (n - 1) + fib (n - 2)

fib

let

Compare

fib = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n - 1) + fib (n - 2) in (map fib' [0 ..] !!)

and

fib x = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n - 1) + fib (n - 2) in map fib' [0 ..] !! x

fib'

x

In contrast to that, in the first case

fib'

where

x

- Haskell-Cafe on Eta-expansion destroys memoization?