Standard libraries

[Bulat Ziganshin]

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 at gmail.com