
Dear Austin,
Wouldn't it be a good idea to link the Vacuum version-number to the
related ghc version number directly as it's functionality is directly
tied to the ghc version anyway.
vacuum 7.4 for ghc 7.4; vacuum 7.2 for ghc 7.2 aso.
Best regards,
Rico Moorman
On Mon, Jul 2, 2012 at 12:04 PM, Austin Seipp
Hi,
Just a word of note: a while back, I decided to take up maintainership of Vacuum and some associated stuff. In the process of doing this, I realized that the ClosureType code in vacuum may not accurately model reality depending on the GHC version. In particular, the definition of ClosureType in vacuum as currently released on Hackage is woefully out of date with respect to Modern GHC. Matt Morrow it seems originally just copied the definition wholesale when he developed it, but as GHC has evolved, so too has the ClosureType definition. Vacuum has not kept up.
I have a github repository[1] containing several cleanups of Vacuum which I'm calling Vacuum 2.0, one of these cleanups being that the ClosureType definition is automatically generated from the GHC definition, and compiled-in accordingly. I have also dropped support for older GHCs (although it could be re-added.)
In this case, based on the changes I made I believe it is fairly unlikely that isThunk would turn up being wrong here. The THUNK* definitions seem to have been relatively untouched over GHC's evolution. But for more advanced functionality, it could possibly result in Vacuum as it stands constructing an invalid heap representation based on object misinterpretations.
I have been busy with a new job but I am not totally absent, and I think I will take this opportunity to release v2.0 in short order, which is mostly intended as a polish and maintenance release for modern GHCs. In the future I would like to see vacuum deprecated and move all its functionality into GHC - much of the code is deeply intertwined with GHC's runtime representations and in some cases I have seen code in the package that was literally copied verbatim from the GHC sources itself, obviously dating several years. It's hard to assess the validity of much of this code. All of this feels brittle and makes me uneasy, and given the complexity of the package as it stands, will make it extremely difficult to maintain as GHC moves forward.
Sorry for the ramble, but I figured it might be relevant if people are going to rely on this functionality.
[1] https://github.com/thoughtpolice/vacuum
On Mon, Jul 2, 2012 at 2:54 AM, Erik Hesselink
wrote: There is also the 'isevaluated' package (which depends on vacuum, but seems to do something more involved than your code).
Erik
On Mon, Jul 2, 2012 at 7:40 AM, Chaddaï Fouché
wrote: On Mon, Jul 2, 2012 at 5:29 AM, Kazu Yamamoto
wrote: Hello,
Are there any ways to see if a value is a thunk or memorized? I would like to have a function like: isThunk :: a -> IO Bool
vacuum allow that and much more though I don't know if it still works correctly on GHC 7.4. Anyway your isThunk is
isThunk a = fmap GHC.Vacuum.ClosureType.isThunk GHC.Vacuum.closureType
(Feel free to arrange your imports to make that a bit more readable ;)
http://hackage.haskell.org/package/vacuum -- Jedaï
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Regards, Austin
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe