ndmitchell
Apply to nested lambdas/functions
Currently only top-level declarations are trapped. However, it should be anything that looks lambda-like, so anything nested as well. e.g.
foo x y = ...
where
bar x y = ...
Should annotate both foo and bar.
This is not immediately useful, because of free variables. The TH wrapper would need to eliminate them, probably via closure conversion or lambda lifting, so not trivial.
It doesn't need to do lambda lifting - as long as it captures the variables again in the lambda. E.g.
foo x y = bar 1 + bar 2
where bar z = ...
Could become:
foo x y = bar 1 + bar 2
where bar (var "z" -> z) = var_ "x" x $ var_ "y" y $ ...
So you are recording x and y in the lambda, but don't have to eliminate them.
I started by looking at what currently happens with your example above. This output is based on calling the function where_1 with params 5 and 7:
What is displayed seems reasonably clear (though the variables z vs z' is maybe a little confusing).
So what would we prefer to see instead?
I just noticed that the operator (*) is not displayed -- a more complicated example will probably show the declarations after the 'where' are not being fully explored.
Regarding the last comment about the (*) operator, I have a fix for that I'll try to put in tomorrow.
The part that is now 'fixed' is the discovery of function application after the 'where'. For the overall issue, though, I was looking for input as to what still needs to be done. See the example above.
Hi,
(debug package for lts-11.3)
I am not getting any traces of the inner go function in this example:
{-# LANGUAGE TemplateHaskell, ViewPatterns, PartialTypeSignatures #-}
{-# OPTIONS_GHC -Wno-partial-type-signatures #-}
module Main where
import Data.Array
import Data.List
import Control.Monad
import Text.Printf
import Debug
debug [d|
fs :: [[Int] -> Int]
fs = [ const 1
, succ . (!! 0)
, succ . (!! 1)
, succ . (!! 2)
]
loeb :: Functor f => f (f a -> a) -> f a
loeb x = go where go = fmap ($ go) x
testLoeb = print $ show $ loeb fs
|]
Instead, only the one call to loeb is traced.
Sorry to hear @clojj - thanks for the report, unfortunately I think all the authors of this project are busy on other things at the moment - but we'll certainly take a look once one of us returns!