Grin abnormality.

[Lemmih]

Greetings,

I was looking through the generated code for a tiny program and I
discovered the strangest thing. Here's the grin code for 'length'
(simplified for clarity):

fW at .fLhc.List.length :: &N -> [bits32]
fW at .fLhc.List.length initList = do
  let f lst acc = do
        nd100000 <- eval lst
        case nd100000 of
          (CLhc.Prim.: head tail) -> do
            acc' <- 1 + acc
            f tail acc'
          [] -> return acc
   in f initList 0

As you can see, this is almost identical to Haskell. This is not what
GRIN should look like.
It seems that JHC/LHC doesn't specialize and inline 'eval'. This is
quite bad as doing so is one of the more important features of GRIN.
Not inlining 'eval' has the following consequences:
  * Since we only use 'nd100000' once, we shouldn't update the closure
with the computed value. We currently cannot perform this
optimization.
  * Function calls are unknown at compile-time.
  * We miss out on inlining opportunities in the arguments to 'length'.
  * We don't have enough information to do (efficient) region inference.

Fixing this will be high on the TODO list.

-- 
Cheers,
  Lemmih