ivan.miljenovic:

Stephen Tetley writes:

...

I had a little experiment along the lines of "A Package Versioning Policy Checker" a few months ago. I got as far as using Haskell-src-exts to extract module export list, but didn't work out out a hashing scheme for the actual type signatures.

I've been thinking of doing something similar for a year or so now, but there's one big problem that I can think of: how to deal with functions that don't have an explicit type signature in the source. My understanding is that to derive these signatures at "checking time" would require using something like the GHC API, which immediately reduces the "niceness" and portability of such a tool/library.

Well, you can 'script' GHC: $ ghc -ddump-types A.hs -fno-code TYPE SIGNATURES replicateM :: forall (v :: * -> *) a. (G.Vector v a) => Int -> IO a -> IO (v a) replicateS :: forall a (m :: * -> *) (v :: * -> * -> *). (Control.Monad.Primitive.PrimMonad m, M.MVector v a) => Int -> a -> m (v (Control.Monad.Primitive.PrimState m) a) To at least get the fully qualified types exported from a module. -- Don

ivan.miljenovic:

Don Stewart writes:

...

Well, you can 'script' GHC:

[snip]

...

To at least get the fully qualified types exported from a module.

Which increases the portability _how_ precisely? :p

Portability? You already have GHC on the machine, right? You don't necessarily need the GHC API to get something prototyped quickly. -- Don

On Thu, Apr 1, 2010 at 7:10 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

Don Stewart writes:

...

Portability? You already have GHC on the machine, right? You don't necessarily need the GHC API to get something prototyped quickly.

I meant in the sense of writing this as a tool, which will also work if the user prefers JHC, YHC, etc. over GHC.

I would suggest in that case that JHC/YHC et al implement sufficient features to support the PVP tool :) Jason

Ivan Lazar Miljenovic wrote:

I've been thinking of doing something similar for a year or so now, but there's one big problem that I can think of: how to deal with functions that don't have an explicit type signature in the source. My understanding is that to derive these signatures at "checking time" would require using something like the GHC API, which immediately reduces the "niceness" and portability of such a tool/library.

As a simple approximation, you could consider functions without type signatures to have changed if their implementation or any function they depend on has changed. Twan

Ivan Lazar Miljenovic schrieb:

Stephen Tetley writes:

...

I had a little experiment along the lines of "A Package Versioning Policy Checker" a few months ago. I got as far as using Haskell-src-exts to extract module export list, but didn't work out out a hashing scheme for the actual type signatures.

I've been thinking of doing something similar for a year or so now, but there's one big problem that I can think of: how to deal with functions that don't have an explicit type signature in the source. My understanding is that to derive these signatures at "checking time" would require using something like the GHC API, which immediately reduces the "niceness" and portability of such a tool/library.

I've done a brief experiment diffing APIs using the hoogle backend of haddock. While the hoogle files where not a perfect match, what are the drawbacks of using a haddock backend if you want to use a GHC API based approach? However, the major problem with a GHC API based approach is that the result relies on the installed dependencies of the package. For example, it is hard to compute the API changes for older versions which do not build anymore. I also believe that inferring the type of an exported function is not a good idea for the PVPC, as this way the result is somewhat indeterministic, depending on installed dependencies. Therefore it seems that a solution based on eg haskell-src-exts, which does not rely on correctly installed dependencies, is preferrable. benedikt

schlepptop:

Don Stewart schrieb:

...

While at ZuriHac, a few of us GSoC mentors got together to discuss what we think the most important student projects for the summer should be.

Here's the list:

http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gso...

Please consider applying to work on these tasks!

For me a cabal-install that can cope with dependencies reliably would be the most important project. (I get frequently bug reports because data-accessor-template cannot be installed by cabal-install although it can be installed with plain Cabal.)

That's interesting. Why can't it be installed? Does data-accessor-template, or somethiing it depends on, have incorrectly specified version ranges? -- Don

Am Samstag 03 April 2010 20:45:47 schrieb Don Stewart:

schlepptop:

...

Don Stewart schrieb:

...

While at ZuriHac, a few of us GSoC mentors got together to discuss what we think the most important student projects for the summer should be.

Here's the list:

http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell- org-gsoc-projects/

Please consider applying to work on these tasks!

For me a cabal-install that can cope with dependencies reliably would be the most important project. (I get frequently bug reports because data-accessor-template cannot be installed by cabal-install although it can be installed with plain Cabal.)

That's interesting. Why can't it be installed? Does data-accessor-template, or somethiing it depends on, have incorrectly specified version ranges?

As a guess, probably http://hackage.haskell.org/trac/ghc/ticket/3799 as exemplified by http://www.haskell.org/pipermail/haskell-cafe/2010- January/072136.html

-- Don