November 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

Why no multiple default method implementations?
by Bas van Dijk 24 Nov '11

24 Nov '11

Hello, Now that we have DefaultSignatures, why is it not allowed to have multiple default method implementations, as in: {-# LANGUAGE DefaultSignatures #-} class Foo a where foo :: a foo = error "foo" default foo :: Num a => a foo = 1 GHC complains: "Conflicting definitions for `foo'" The following use of multiple default signatures also gives the same error: class Foo a where foo :: a default foo :: Fractional a => a foo = 0.5 default foo :: Num a => a foo = 1 Couldn't GHC always pick the most specific default method, just as it does with instances when OverlappingInstances is enabled? Regards, Bas

2 2

Fwd: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6)
by Simon Marlow 24 Nov '11

24 Nov '11

This deserves a wider audience: if you've encountered failures when compiling FFI code with recent GHCs due to the new requirement that newtypes be non-abstract, note that this will now be a warning, not an error, in 7.4.1. We're deferring turning it into an error until 7.6.1. Cheers, Simon -------- Original Message -------- Subject: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6) Date: Thu, 24 Nov 2011 06:57:21 -0800 From: Simon Marlow <marlowsd(a)gmail.com> To: cvs-ghc(a)haskell.org Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/c6b0fd62fc715aa6c666eb8afe090… >--------------------------------------------------------------- commit c6b0fd62fc715aa6c666eb8afe09073ac7b87a83 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Thu Nov 24 14:04:23 2011 +0000 Relax the restriction on using abstract newtypes in FFI declarations. Given the high impact of this change, we decided to back off and make abstract newtypes give a warning for one release, before we make it an error in 7.6.1. Codec/Compression/Zlib/Stream.hsc:884:1: Warning: newtype `CInt' is used in an FFI declaration, but its constructor is not in scope. This will become an error in GHC 7.6.1. When checking declaration: foreign import ccall unsafe "static zlib.h deflate" c_deflate :: StreamState -> CInt -> IO CInt >--------------------------------------------------------------- compiler/typecheck/TcForeign.lhs | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/compiler/typecheck/TcForeign.lhs b/compiler/typecheck/TcForeign.lhs index 886b84d..5a4bf77 100644 --- a/compiler/typecheck/TcForeign.lhs +++ b/compiler/typecheck/TcForeign.lhs @@ -121,17 +121,29 @@ normaliseFfiType' env ty0 = go [] ty0 panic "normaliseFfiType': Got more GREs than expected" _ -> return False - if newtypeOK - then do let nt_co = mkAxInstCo (newTyConCo tc) tys - add_co nt_co rec_nts' nt_rhs - else children_only + when (not newtypeOK) $ + -- later: stop_here + addWarnTc (ptext (sLit "newtype") <+> quotes (ppr tc) <+> + ptext (sLit "is used in an FFI declaration,") $$ + ptext (sLit "but its constructor is not in scope.") $$ + ptext (sLit "This will become an error in GHC 7.6.1.")) + + let nt_co = mkAxInstCo (newTyConCo tc) tys + add_co nt_co rec_nts' nt_rhs + | isFamilyTyCon tc -- Expand open tycons , (co, ty) <- normaliseTcApp env tc tys , not (isReflCo co) = add_co co rec_nts ty + | otherwise - = children_only + = return (mkReflCo ty, ty) + -- If we have reached an ordinary (non-newtype) type constructor, + -- we are done. Note that we don't need to normalise the arguments, + -- because whether an FFI type is legal or not depends only on + -- the top-level type constructor (e.g. "Ptr a" is valid for all a). where + children_only = do xs <- mapM (go rec_nts) tys let (cos, tys') = unzip xs return (mkTyConAppCo tc cos, mkTyConApp tc tys') _______________________________________________ Cvs-ghc mailing list Cvs-ghc(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

1 0

Re: Why not allow empty record updates?
by wren ng thornton 23 Nov '11

23 Nov '11

On 11/15/11 8:07 PM, wagnerdm(a)seas.upenn.edu wrote: > Quoting wren ng thornton <wren(a)freegeek.org>: >> So far I've just defined helper functions to adjust the phantom >> type[1], each of which is implemented by (\x -> x { foo = foo x }). >> It's a horrible hack, but at least it's hidden away in library >> functions instead of something I have to look at. The annoying part > > (a bit tongue-in-cheek, and hence not sent to the mailing list) Forwarding to the list, because I actually have a serious response :) > As long as we're writing hacks, why not use unsafeCoerce? ;-) In this particular case I don't care too much about representation sharing (though I do share Ed's concern), and I generally do my best to avoid unsafeFoo just so I can minimize my personal proof obligations / maximize the utility of the compiler's type checking. Though, yes, in other projects with similar considerations I've also gone the unsafeCoerce route. Other than invalidating type system guarantees, it does have the side effect that it can interfere with rewrite rules firing (since the coercion remains in the System Fc core). And the times when I really care about representation sharing are often also the times I really care about rewrite rules firing. Which in turn means I tend to add additional rewrite rules to push the unsafeCoerce around in order to get it out of the way so that other rules can fire. But I see no way of specifying these additional rules in full generality while retaining correctness--- without some additional mechanism to say things like "this newtype wrapper is opaque in these contexts (to preserve the abstract semantics), but is translucent in these other contexts (to abide by categorical laws like functorality). It's really unfortunate that these complementary goals of sharing representation and doing rewrites/fusion are at odds in current Haskell. I run into similar issues with needing to work around coercions in Coq, since they impede the evaluator and proofs of value equality due to the weakness of Coq's case analysis. That the issue shows up in Coq as well seems to imply that the root of the problem is something deeper than noone having implemented the convenience. Agda has a stronger case analysis and so doesn't run into quite the same issues, though I'm not entirely clear on the exact ways in which Agda's case analysis gains that extra power, so it's unclear whether we could (meaningfully) add the power to Haskell without going whole hog into dependent types. Of course, this all is related to the problem of strong updates; it just happens that the update is Curry-identical, yet Church-different. Given the general preference for Church-style lambda calculi, it's not surprising that this exact problem hasn't been tackled (to my knowledge). Another place this problem has come up for me is in wanting to ensure representation sharing for values constructed by data constructors which don't make use of their type parameters. A trivial example would be sharing the representation of Nothing between all the Maybe types, or sharing the empty list among all the list types. That example isn't especially motivating, but there are other cases where we can end up with a large structure for which the type parameters are 'phantom' even though they may not be phantom in general (because other data constructors make use of them). That we want type updates for records with phantom types is just a symptom of the larger issue of wanting type updates for all quasiphantom/pseudophantom types. -- Live well, ~wren

2 1

What makes GHC's GC good for purely functional workloads?
by Edward Z. Yang 23 Nov '11

23 Nov '11

Apologies if this has been asked before. In some ways GHC's garbage collectors are very traditional, so I was wondering what magic dust makes it do better in Haskelly workloads (e.g. whereas you'd need to do a bit more work in the JVM to make some allocation pattern play nice.) Edward

3 3

Stable names and type constraints
by Lee Pike 23 Nov '11

23 Nov '11

Hi Everybody, This is a question about System.Mem.StableName <http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.4.1.0/System-M…>---let me know if this isn't the right forum, but my understanding is that stable names are GHC-specific. Consider the module below. For a function with type constraints, stable names fails to "realize" that we are pointing to the same object. As a couple of my colleagues pointed out to me, the cause is the dictionary being passed around causing new closures to be created. This can be rectified using a local variable binding (e.g., using a where clause), but it'd be nice if there were a solution to allow for observable sharing, even for functions with type constraints. Are there known solutions other than monomorphism or local variable bindings? Thanks, Lee ------------------------------------------------------------------------------- module Test where import System.Mem.StableName (StableName, makeStableName) --------------------------------------------------------------------------------- type Map a = [StableName (Expr a)] analyze :: Expr a -> IO (Map a) analyze = analyzeExpr [] analyzeExpr :: (Map a) -> Expr a -> IO (Map a) analyzeExpr env e@(Op e0) = do sn <- makeStableName e if elem sn env then return env else analyzeExpr (sn : env) e0 --------------------------------------------------------------------------------- -- Language, with one constructor class Typed a where instance Typed Int data Expr a = Op (Expr a) expr0 :: Expr a expr0 = Op expr0 expr1 :: Typed a => Expr a expr1 = Op expr1 expr2 :: Typed a => Expr a expr2 = x where x = Op x --------------------------------------------------------------------------------- -- Tests -- Returns 1 test0 :: IO () test0 = test (expr0 :: Expr Int) -- Doesn't terminate! test1 :: IO () test1 = test (expr1 :: Expr Int) -- Returns 1 test2 :: IO () test2 = test (expr2 :: Expr Int) test :: Expr a -> IO () test e = analyze e >>= putStrLn . show . length

2 1