Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
On Sat, Apr 3, 2010 at 12:45 PM, Don Stewart wrote: > 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? > I'm no cabal expert, but I've had the same issue with other packages - when it needs to build different with different versions of of template-haskell the easiest thing to do is to have a flag in the package description for different versions of the template-haskell packages. But then cabal-install thinks it can use either version in its install plan, but it really can't as template-haskell is one of the libs that is tied to your GHC install (even after fixing old th for GHC 6.12 and installing it, you cannot use it). So you either default to 6.12 compatible or 6.10 compatible, and then loose the other compiler when your package is included one step deep (or further) in a cabal-install install plan. The solution I lean towards is to use the MIN_VERSION_TEMPLATE_HASKELL cpp macro, what Henning has last tried is setting the package flag off of the GHC version (which works because template-haskell is keyed to your GHC install). In summary - don't specify versions of template-haskell in your package description. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Ivan Lazar Miljenovic schrieb: 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. The tool could just reject definitions without signature because it is not nice style. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
On 2 April 2010 07:22, Twan van Laarhoven wrote: > > 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. > Ah, too much work. Having libraries where the exported functions have signature seems more desirable than no signatures (documentation benefit, at least). So a tool could just print a warning "No type signature for _export-name_". This would be an effective social obligation to encourage people to add signatures to exported functions. Also other developers could see the library wasn't using export signatures and be cautious about depending on it themselves. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
On Thu, Apr 1, 2010 at 7:10 PM, Ivan Lazar Miljenovic < ivan.miljeno...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
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. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The 8 Most Important GSoC Projects
Hello All 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. The project is minimal, but it does have code to reconcile module paths from a Cabal file using the Distribution library (which was more work than I imagined). It might make a reasonable starting point if someone wants to pick it up - afraid I'm not a student nor could I commit to being a mentor. http://copperbox.googlecode.com/files/precis-0.1.0.tar.gz Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
