Hello haskell-prime, one more proposal is about standard libs. it is well known that today libs outweighs all other parts of modern language and work on their standardization will probably stall the whole Haskell-prime process. OTOH, languages like Java was grown due to their rich set of libraries, which is far more than any committee may even discuss, all the more invent. afaiu, Java versions just standardize libraries that are in wide use on the moment of standard acceptance i propose to do the same. first, library developers should follow http://haskell.org/haskellwiki/Package_versioning_policy second, every year Haskell committee should decide which libraries of currently Hackage-available are most widely used, portable and free, and call this set a "Haskell-xxxx standard libraries", together with versions inspected. Next year some libs may disappear from the list, some new appear and some upgrade to newer versions. so, we may had: 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 Third, each compiler shipped should declare which HSL (Haskell Standard Libraries) versions it supports. F.e.: ghc 7.10: HSL 2010-2014 ghc 7.12: HSL 2011-2014 ... So, every new compiler version will try to support newest HSL versions and try to keep compatibility with old ones while they last in wide use, and newer compilers/platforms may be supported by old libs by publishing their minor modifications (base 3.0.1, base 3.0.2 and so on) Fourth, this may make Haskell education more organized - i.e. book or course may declare that it teaches Haskell-2008 standard with HSL-2010 libraries and this will mean that at the end programmer will be able to use some set of functionality (i.e. all the libs included in the HSL-2010) and that his knowledge will allow him to immediately start working with ghc 7.0-8.10, hugs 2010-2015 and jhc 1.0-1.5, for example 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 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Thu, Nov 15, 2007 at 10:54:28AM +0300, Bulat Ziganshin wrote:
second, every year Haskell committee should decide which libraries of currently Hackage-available are most widely used, portable and free, and call this set a "Haskell-xxxx standard libraries", together with versions inspected.
See also: http://hackage.haskell.org/trac/haskell-prime/ticket/118 (We should also write down somewhere exactly which libraries must follow http://www.haskell.org/haskellwiki/Library_submissions)
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.
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. Thanks Ian
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
participants (2)
-
Bulat Ziganshin -
Ian Lynagh