From bulat.ziganshin at gmail.com Thu Nov 15 02:24:29 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 15 02:50:18 2007 Subject: Haskell'2008 Message-ID: <536221415.20071115102429@gmail.com> Hello haskell-prime, i propose to omit type functions/families from standard you are currently developing and leave only MPTC (without FDs) here reason: it not yet included in GHC. probably, it will be in 6.10 next fall. then we will need one more year to prove its usefulness and one more year to finish developing new Haskell standard. at this time we will also have many new ghc/hugs extensions which will be again very appetite instead, i propose to make H2008 standard and be ready to update it each 3-4 years -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Nov 15 02:54:28 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 15 02:56:45 2007 Subject: Standard libraries Message-ID: <35775467.20071115105428@gmail.com> 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 From igloo at earth.li Thu Nov 15 09:34:59 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Nov 15 09:31:34 2007 Subject: Standard libraries In-Reply-To: <35775467.20071115105428@gmail.com> References: <35775467.20071115105428@gmail.com> Message-ID: <20071115143459.GA21671@matrix.chaos.earth.li> 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 From bulat.ziganshin at gmail.com Thu Nov 15 15:58:54 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 15 16:02:15 2007 Subject: Standard libraries In-Reply-To: <20071115143459.GA21671@matrix.chaos.earth.li> References: <35775467.20071115105428@gmail.com> <20071115143459.GA21671@matrix.chaos.earth.li> Message-ID: <577425023.20071115235854@gmail.com> 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 From ndmitchell at gmail.com Wed Nov 28 08:37:19 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Nov 28 08:33:16 2007 Subject: Show instance of Ratio Message-ID: <404396ef0711280537n19f030ecyba85b922967c9c03@mail.gmail.com> Hi The GHC Show instance of Ratio is different from that in Yhc/Hugs/The Report. There has been a discussion in the bug tracker, which you can follow at http://hackage.haskell.org/trac/ghc/ticket/1920 . I thought I'd summarise everyone's positions, and the possible actions we can take. Problem ------------- showing a Ratio using GHC places no spaces around the "%", in Hugs/Yhc/The Report it has spaces. Read the bug tracker for an example. Solution ------------ EITHER: Make all compilers put out spaces OR: Make no compilers put out spaces The alternative is to have different compilers do different things, which I think we can agree is bad (TM). As a more general point, should all infix constructors have spaces around them or not. Whatever we decide, it would be weird for it to apply to only the Ratio instance and not others. I think we should solve this problem now. It makes sense to come to some consensus which Haskell' will follow, then fix whichever set of compilers is determined to be wrong. Opinions -------------- The basic differing of opinions is should Show print the minimal ASCII representation (Neil Mitchell, Simon Marlow) or something that is slightly pretty where possible (Ross Patterson, Ian Lynagh). Comments welcome. Thanks Neil