Hello Ian, Thursday, November 15, 2007, 5:34:59 PM, you wrote:
H2008 libs: base 3.0, FPS 1.0, Binary 1.0 H2009 libs: base 3.0, FPS 2.0, SuperBinary 0.1
With above-mentioned versioning policy, this means that any "FPS 1.0.*" will comply to the H08 standard and this means that this line of version may continue to fix bugs, improve performance, add support for new systems, while keeping its interface
Note that according to the versioning policy FPS 1.0.1 can, for example, export functions that 1.0.0 doesn't export.
it is Simon's version. my version was: * major version change (2.2->3.0) means total incompatibility. all sorts of changes may come * middle version change (2.1.3->2.2) means addition of new facilities (functions, constructors, classes...). in most cases, such semi-compatible version can be used if that's done with caution * minor change (2.1.1->2.1.2) means only internal changes and bugfixes
One important drawback that i see here is that "full" compiler downloads should be shipped with older library versions too - i.e. providing newest FPS library will be not enough, you need to ship older HSL libraries too
Personally I think it is best to avoid having more than one version of a library installed. That way you don't have problems when you try to use 2 libraries, and one thinks that ByteString is fps-1.0:Data.ByteString.ByteString and another that it is fps-2.0:Data.ByteString.ByteString, resulting in type mismatch errors.
the same problem will exist when you installed libraries fps10 and fps20, nevertheless ghc now allows this the real problem is when user tries to use two different libraries with the same-named types in his library/application (doesn't matter whether it's fps1.0+fps2.0 or fps10+fps20). but it's impossible - one cannot decalre that his program uses fps10 and fps20 and import BS module which contained in both libs. moreover, when he will try to "marry" some code that works with BS type in 3rd-party libs Binary1 and Binary2 (relying on corresponding FPS* libs), he will have some module Both.hs which imports both types and then use them interchangeably. at this module GHC will just complaint: Expected type: FPS10.Data.ByteString.ByteString Real type: FPS20.Data.ByteString.ByteString as you see - no problems as David said, providing old versions is essential for backward compatibility, for developing softawre that "just works". at this moment each new ghc version can't compile large apps developed for previous one -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com