two memfib rewrites with LETs

;;https://stackoverflow.com/questions/60331920/partial-application-versus-pattern-matching-why-do-these-haskell-functions-beha#comment106748884_60331920

there is no guarantee in the *language* for CAFs to be [memoizing](https://wiki.haskell.org/Memoization#Memoising_CAFS) (i.e. for `theCache` to be pushed over the lambda), AFAIK, it is something GHC implementors decided to do (?).

1.

memfib = (!!) (map fib [0..])
  where
    fib 0 = 0
    fib 1 = 1
    fib k = memfib(k-2) + memfib(k-1)
  =
  let  { mapfib = (map fib [0..]) }  in  (!!) mapfib   -- THIS CRUCIAL STEP
      where
        fib 0 = 0
        fib 1 = 1
        fib k = memfib(k-2) + memfib(k-1)
  =
   -- where's scope is attached to the definition `memfib =`, so is above all else
  let
    fib 0 = 0
    fib 1 = 1
    fib k = memfib(k-2) + memfib(k-1)
   in
     let { mapfib = (map fib [0..]) }
     in  \n -> (!!) mapfib n               -- eta-expansion NOW

  -- fib is above mapfib, scope-wise, but the two scopes
  -- can be squashed together into one LET just the same

2.

memfib_wparam -- n =  ((!!) (map fib [0..])) n
              = \n -> ((!!) (map fib [0..])) n    -- parameter syntax is sugar for lambdas
  where
    fib 0 = 0
    fib 1 = 1
    fib k = memfib_wparam(k-2) + memfib_wparam(k-1)
  =
  -- where can't be part of lambda, so fib is above the lambda, scope-wise
   let
    fib 0 = 0
    fib 1 = 1
    fib k = memfib_wparam(k-2) + memfib_wparam(k-1)
  in
    \n -> ((!!) (map fib [0..])) n
                --------------
                -- -CSE could float this too, if it chose to !