September 2011 - Glasgow-haskell-users

Records in Haskell
by Simon Peyton-Jones 27 Mar '12

27 Mar '12

Friends Provoked the (very constructive) Yesod blog post on "Limitations of Haskell", and the follow up discussion, I've started a wiki page to collect whatever ideas we have about the name spacing issue for record fields. http://hackage.haskell.org/trac/ghc/wiki/Records As Simon M said on Reddit, this is something we'd like to fix; but we need a consensus on how to fix it. Simon

41 183

ANNOUNCE: GHC version 7.2.1
by Ian Lynagh 27 Mar '12

27 Mar '12

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.2.1 ============================================================= The GHC Team is pleased to announce a new major release of GHC, 7.2.1. The 7.2 branch is intended to be more of a "technology preview" than normal GHC stable branches; in particular, it supports a significantly improved version of DPH, as well as new features such as compiler plugins and "safe Haskell". The design of these new features may evolve as we get more experience with them. See the release notes for more details of what's new and what's changed. We are also using this branch as an opportunity to work out the best workflows to use with git. We expect the 7.2 branch to be short-lived, with 7.4.1 coming out shortly after ICFP as normal. Full release notes are here: http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/release-7-2-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

9 16

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ANNOUNCE: GHC 7.2.1 Release Candidate 1
by Ian Lynagh 11 Feb '12

11 Feb '12

We are pleased to announce the first release candidate for GHC 7.2.1: http://www.haskell.org/ghc/dist/7.2.1-rc1/ This includes the source and testsuite tarballs, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

8 23

Proposal to incorporate Haskell.org
by Don Stewart 16 Dec '11

16 Dec '11

Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) ------------------------------------------------------------------------ = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) <http://conservancy.softwarefreedom.org/>. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence <http://www.opensource.org/licenses/alphabetical>. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium <http://www.haskell.org/haskell-symposium/> and Industrial Haskell Group<http://industry.haskell.org/> webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation "The Haskell Foundation" was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed "community.haskell.org" in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation

4 5

Two Proposals
by George Giorgidze 10 Oct '11

10 Oct '11

GHC Users, I would like to make to the following two proposals: * Eliminate the default grouping close from SQL-like comprehensions * Introduce a GHC extension for list literal overloading OK, let me start with the first proposal. Currently, the SQL-like comprehension notation (both in its list comprehension and monad comprehension variants) features the following five clauses: then f then f by e then group by e then group using f then group by e using f The first two clauses are used for specifying transformations of type [a] -> [a] (or Monad m => m a-> m a for monad comprehensions). The following three clauses are used for specifying transformations of type [a] -> [[a]] (or Monad m, Functor f => m a -> m (f a) for monad comprehensions). See [1] for further details. Note that the third clause does not mention which function is used for grouping. In this case GHC.Exts.groupWith function is used as a default for list comprehensions and the mgroupWith function from the MonadGroup class is used as a default for monad comprehensions. I would like to suggest to remove the third clause for the following reasons: * Currently the syntax is asymmetrical. Note that there is the default case for the 'then group' clause and not for the 'then' clause. * In the current notation it is not clear which grouping function is used in the default case * For many monads including lists it is not clear which function should be selected as a default (e.g., the groupWith function also does sorting and it is not clear to me why this should be the default) * Gets rid of the MonadGroup class. Currently the sole purpose of this class is to introduce a default grouping function for monad comprehensions. * Explicit mention of the grouping function would make monad/list comprehensions much easier to read by making it immediately apparent which function is used for grouping. My second proposal is to introduce the OverloadedLists extension that overloads list literals. See Section 5.2 in [1] for details. Basically the idea is to treat list literals like: [1,2,3] as fromList [1,2,3] where class IsList l where type Item l fromList :: [Item l] -> l In the following I give useful instances of the IsList class. instance IsList [a] where type Item [a] = a fromList = id instance (Ord a) => IsList (Set a) where type Item (Set a) = a fromList = Set.fromList instance (Ord k) => IsList (Map k v) where type Item (Map k v) = (k,v) fromList = Map.fromList instance IsList (IntMap v) where type Item (IntMap v) = (Int,v) fromList = IntMap.fromList instance IsList Text where type Item Text = Char fromList = Text.pack As you can see the extension would allow list literals to be used for sets, maps and integer maps. In addition the suggested OverloadedLists extension would subsume OverloadedStrings extension (see the instance for Text, for example). Having said that, for now, I am not suggesting to remove the OverloadedStrings extension as it appears to be widely used. This extension could also be used for giving data-parallel array literals instead of the special syntax used currently. Unless there is a vocal opposition to the aforementioned two proposals, I would like to implement them in GHC. Both changes appear to be straightforward to implement. Thanks in advance for your feedback. Cheers, George [1] http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf

12 19

Mysterious function timer_settime
by Volker Wysk 06 Oct '11

06 Oct '11

Hi! Im porting my HsShellScript library to GHC-7.0.4 and to Cabal/Hackage. It builds and installs fine: ~/src/hsshellscript-3.0.0 $ cabal clean cleaning... ~/src/hsshellscript-3.0.0 $ cabal configure Resolving dependencies... Configuring hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal build Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... (...) Registering hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal haddock Running Haddock for hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... (...) Documentation created: dist/doc/html/hsshellscript/index.html ~/src/hsshellscript-3.0.0 $ cabal install Resolving dependencies... Configuring hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... Registering hsshellscript-3.0.0... Installing library in /home/v/.cabal/lib/hsshellscript-3.0.0/ghc-7.0.4 Registering hsshellscript-3.0.0... I've made a fine little test program src/test.hs: import HsShellScript main = (outm "3\n1\n2\n") -|- exec "/usr/bin/sort" ["-n"] But this doesn't work. It generates a mysterious error message: ~/src/hsshellscript-3.0.0 $ src/test test: <stderr>: hPutStr: illegal operation (handle is closed) test: timer_settime: Invalid argument "timer_settime" occurs only in the generated test binary. It doesn't occur anywhere in the library or in "/usr/bin/sort": ~/src/hsshellscript-3.0.0 $ find -type f -print0|xargs -0 egrep timer_settime Übereinstimmungen in Binärdatei ./src/test. ~/src/hsshellscript-3.0.0 $ egrep timer_settime /usr/bin/sort (no output) It looks like GHC has introduced this mysterous call of timer_settime. What does that mean? Thanks for any help, Volker W.

2 3

Re: [Pkg-haskell-maintainers] libffi soname change upcoming
by Joachim Breitner 04 Oct '11

04 Oct '11

Hi, Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose: > > The question that has to be answered first is: Assume the libraries do > > not depend on libffi themselves, and only ghc does. Now you update > > libffi and ghc gets rebuilds, what will happen: > > > > A) The haskell ABIs stay the same, the existing library packages can > > still be used. Great. > > > > B) The haskell ABIs change. We’ll have to binNMU all Haskell libraries, > > but oh well, not bad thanks to BD-Uninstallable-support in wanna-build > > and autosigning. > > > > C) The haskell ABIs do not change, but the old library builds are > > broken nevertheless. Big mess. Hard to recover from, because builds are > > not ordered automatically any more. Needs lots of NMUes and Dep-Waits. > > sorry, I don't get the `C' case. why should these be broken by a libffi or > libgmp change? Maybe it’s an unrealistic example, but I could imagine that ghc some data type (size) defined by libffi is used when generating code for a haskell library under the assumption that it has the same structure/size in the run time system and/or other used haskell libraries. But instead of making blind guesses, maybe GHC upstream can enlighten us: Is it safe to build ghc and a Haskell library, then upgrade libffi to a new version (with soname bump), rebuild ghc, but use the previous library build? > > Removing the libffi dependencies from the haskell libraries makes C > > possible and only helps with A. So until someone investigates this, I’d > > rather err on the safe side, leave the dependencies in, and fix the > > issue by rebuilding all haskell libraries when you upload the new ffi > > soname to unstable. > > well, with binNMU orgies like this you'll pull in any new or tightened > dependencies for shared libraries. Not depending on these unused libraries > does avoid this. True. I agree that it would be nice and worthwhile to remove the libffi dependency from the libraries, but only if it is actually safe and scenario C is guaranteed not to happen. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 4

Segfault while building GHC HEAD on Mac OS X 10.7/XCode 4.1
by Johan Tibell 29 Sep '11

29 Sep '11

The build fails with a segfault when building HEAD using GHC 7.2, OS X 10.7, and XCode 4.1 Any ideas? tibbe@redwood:ghc (master)$ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -H64m -O -fasm -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O -dcore-lint -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Debug.hs -o libraries/ghc-prim/dist-install/build/GHC/Debug.o make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Debug.o] Segmentation fault: 11 make: *** [all] Error 2

2 1

Associativity of the generic representation of sum types
by Bas van Dijk 26 Sep '11

26 Sep '11

Hello, I just used the new GHC generics together with the DefaultSignatures extension to provide a default generic implementation for toJSON and parseJSON in the aeson package: https://github.com/mailrank/aeson/pull/26 It appears that the generic representation of a sum type has a tree shape as in: (a :+: b) :+: (c :+: d) In my case this tree-shaped representation is problematic when parsing a JSON value to this type. My overloaded parsing function is parameterized with a key which specifies which of the a, b, c or d constructors to parse. When it encounters a constructor it checks if it matches the key, if so it is parsed, if not parsing will fail. Because of the tree-shaped representation of sum types I have to recursively parse the left and right branch and join them using <|>: https://github.com/basvandijk/aeson/blob/d5535817ceb192aa9d7d0d0b291e1901f3… I don't know for sure but I suspect that this can cause memory leaks since the <|> has to keep the right value in memory when it is parsing the left. Ideally the generic representation of sum types is right associative as in: a :+: (b :+: (c :+: d)) This way I only have to check if 'a' matches, if it does the right branch can be forgotten. Is there a good reason for not having it right associative? Regards, Bas

2 7