November 2007 - Haskell-prime

Show instance of Ratio
by Neil Mitchell 28 Nov '07

28 Nov '07

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

1 0

Standard libraries
by Bulat Ziganshin 15 Nov '07

15 Nov '07

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

2 2

Haskell'2008
by Bulat Ziganshin 15 Nov '07

15 Nov '07

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

1 0