2018 Mon Mar 12

Carefully alter

Had some kind of issue with a MySQL table today. Possibly because of a bad ALTER. Attempted a column alteration from VARCHAR to INT with length 11 but my db client application (MacOS, Sequel Pro) hung at this point. I force quit but since then I think the table has been unloadable. Attempting to access says loading indefinetely. Will investigate solution tomorrow but lesson today. Next time doing alter:

1. copy table structure to new temp table
2. make alterations
3. copy data
4. delete old table
5. rename new table to old

Haskell let v where

Haskell has two ways of binding variables let and where. let is an expression and where is a declaration. The difference is let can go wherever an expression can go. For example:

Prelude
𝝺 a = let b = 2 in b

Prelude
𝝺 a
2

Prelude
𝝺 b

<interactive>:5:1: error: Variable not in scope: b

1. We assign an expression to a which itself contains a let binding assigned 2 to b. We just return b there.
2. We prove that a has been assigned the bound value to b
3. We prove that the binding b was local to the expression within assignment to a.

On the other hand since where is bound to syntactic structure it can provide some unique affordances to the user. For example it introduces variables across function pattern matches:

Prelude
𝝺 :{
Prelude| foobar 1 = 1 + a
Prelude| foobar 2 = 2 + a
Prelude| foobar _ = a
Prelude|   where a = 10
Prelude| :}

Prelude
𝝺 foobar 1
3

Prelude
𝝺 foobar 2
4

Prelude
𝝺 foobar 3
10

Note how the a = 10 binding was in scope for all three pattern-matched definitons of foobar.

Regarding this topic there is considerably more detail on the Haskell Wiki. It seems that the main advantage of where is its readability. Even the ability to share where across multiple function pattern matches can be achieved somewhat using case-of.

Lambda Lifting

Turn Free Variables (those not found in the function's parameters) into arguments. For example:

foo a =
  a + b
  where
    b = a + 1

foo a =
  a + b a
  where
    b a = a + 1