Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? Programs which use an upper bound on their fgl dependency, as the PvP advises, won't break. A complete rewrite with a new maintainer: fgl-awesome In 10 years time, we don't want to have fgl fgl-awesome fgl-great fgl-joe which all do the same thing, and have an unclear relationship to each other. I think the important question is: Once the new FGL is finished, will there be a good reason (other than backwards compatibility) for people to use the current FGL? If yes, then different names should be used. Otherwise, no matter how different the API is, keeping the same name is the right thing to do. So if there is consensus that the new design is a better fgl, I think it ought to keep the name. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Ian Lynagh ig...@earth.li writes: On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: A complete rewrite with a new maintainer: fgl-awesome In 10 years time, we don't want to have fgl fgl-awesome fgl-great fgl-joe which all do the same thing, and have an unclear relationship to each other. Definitely (though hopefully we wouldn't pick names like fgl-awesome anyway...). I think the important question is: Once the new FGL is finished, will there be a good reason (other than backwards compatibility) for people to use the current FGL? If yes, then different names should be used. Otherwise, no matter how different the API is, keeping the same name is the right thing to do. And this is why we're going to request the community's input on our API design: to try and avoid the situation where there's a specific reason to keep using the old one. As it stands, the only real advantage that I can think of is that the new version uses extensions, the old version doesn't (and hence is more compatible). So if there is consensus that the new design is a better fgl, I think it ought to keep the name. Which is what we're trying to build (the consensus, that is). Don has started a wiki page with the arguments here, and I've already added my 2c: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Ian Lynagh ig...@earth.li writes: On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: A complete rewrite with a new maintainer: fgl-awesome In 10 years time, we don't want to have fgl fgl-awesome fgl-great fgl-joe which all do the same thing, and have an unclear relationship to each other. Definitely (though hopefully we wouldn't pick names like fgl-awesome anyway...). I think the important question is: Once the new FGL is finished, will there be a good reason (other than backwards compatibility) for people to use the current FGL? If yes, then different names should be used. Otherwise, no matter how different the API is, keeping the same name is the right thing to do. And this is why we're going to request the community's input on our API design: to try and avoid the situation where there's a specific reason to keep using the old one. As it stands, the only real advantage that I can think of is that the new version uses extensions, the old version doesn't (and hence is more compatible). So if there is consensus that the new design is a better fgl, I think it ought to keep the name. Which is what we're trying to build (the consensus, that is). Don has started a wiki page with the arguments here, and I've already added my 2c: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename -- 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
[Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Oh, great, the email _did_ go out on the mailing lists (what with haskell.org being down I wasn't sure it would). Don Stewart d...@galois.com writes: ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome We considered giving it a new name (fgl', etc.) but figured that in the long term this wouldn't be advantagous. We feel that the situation is analogous to QuickCheck: when the new version came out most people kept using the old one until slowly the momentum shifted and more people started using the new version (without checking in depth, Roel's Hackage mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 reverse dependencies for QC-1.y). If we changed the name, then the emotional attachment that the Haskell community has to FGL being the de-facto graph library means that people would keep using the old version. Whilst we also face the possible problems of people not liking the old version and thus automatically dismissing the new version, I think this is a much more unlikely scenario. The overall philosophy is remaining the same: we're just updating the implementation (letting people pick the Node type rather than hard-coding it to Int, letting people constrain the label types and also providing more scope for optimisations). As such, the new version is incompatible with the old one; however, if you're only _using_ FGL (as opposed to making a new instance of the graph types), then the actual changes to using the new version should be minimal (especially if you're using it internally in which case you can hard-code the various types in and not have to worry about the type family usage at all). As I said, I've directly emailed the maintainers of the packages that have open-ended dependencies on FGL and thus would have compilation problems when we release the new version[s]; 7 out of 12 of those maintainers have already responded within less than 24 hours so I don't think this is likely to be a problem unless some new package is uploaded in the near future without proper ranged dependencies. So as to give you even more of a heads up, here are some more overall plans Thomas and I have for FGL: * FGL will still focus on inductive graphs; however the two current classes are being combined since it doesn't make much sense in general to have a graph that can be decomposed using match but can't be composed using (there might be specific cases where this is true such as considering the Cabal package dependency graph; however this is likely to be defined internally within some project so users should just be careful about how they use it to ensure they don't add arbitrary nodes/edges that don't make sense; note that the new Show and Read instances take advantage of this by using Contexts as the basis of this instance). * The ability to have proper Eq, Show and Read instances for graphs with pre-defined helper functions implementors can use (currently Data.Graph.Inductive.Tree has a pretty output for Show but no Read instance, and graphs cannot have equality due to overlapping instance problems). * Splitting the library up into the base classes + sample instances (the fgl package) and a separate fgl-algorithms package (analogous to Dan Doel's vector-algorithms; this will be comprised of what is currently in the Data.Graph.Inductive.Query.* modules as well as the Data.Graph.Analysis.Algorithms.* modules in my Graphalyze library. The Data.Graph.Inductive.Graphviz module will also be scrapped in favour of my graphviz library. * By default, fgl will ship with two default instances: the one currently in Data.Graph.Inductive.PatriciaTree and also a generic Map-based one that lets people choose their own Node type (i.e. the key type in the Map). Any other suitable instances that we can think of (e.g. Thomas has the beginnings of a vector-based one) we'll ship in separate packages (e.g. fgl-vector). If anyone has a good reason to object to any of these plans, we are willing to be persuaded out of them. This is why the 6.z series of fgl will be technology previews to slowly build up what FGL does and gauge the reaction of the Haskell community. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
