April 2010 - Glasgow-haskell-users

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

Parallel Haskell: 2-year project to push real world use
by Duncan Coutts 08 May '10

08 May '10

GHC HQ and Well-Typed are very pleased to announce a 2-year project funded by Microsoft Research to push the real-world adoption and practical development of parallel Haskell with GHC. We are seeking organisations to take part: read on for details. In the last few years GHC has gained impressive support for parallel programming on commodity multi-core systems. In addition to traditional threads and shared variables, it supports pure parallelism, software transactional memory (STM), and data parallelism. With much of this research and development complete, and more on the way, the next stage is to get the technology into more widespread use. This project aims to do the engineering work to solve whatever remaining practical problems are blocking organisations from making serious use of parallelism with GHC. The driving force will be the *applications* rather than the *technology*. We will work in partnership with a small number of commercial or scientific users who are keen to make use of parallel Haskell. We will work with these partners to identify the issues, major or minor, that are hindering progress. The project is prepared to handle system issues, covering everything from compiler and runtime system through to more mundane platform and tool problems. Meanwhile our partners will contribute their domain-specific expertise to use parallel Haskell to address their application. We are now seeking organisations to take part in this project. Organisations do not need to contribute financially but should be prepared to make a significant commitment of their own time. We expect to get final confirmation of the project funding in June and to start work shortly thereafter. Well-Typed will coordinate the project, working directly with both the participating organisations and the Simons at GHC HQ. If you think your organisation may be interested then get in touch with me, Duncan Coutts, via info(a)well-typed.com. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 7

strong type derivation in ghc 6.12 compared to 6.12
by Seyed Hosein Attarzadeh Niaki 07 May '10

07 May '10

I have problems with upgrading some already working code for GHC 6.12. The following code: ----------------------------------------------------------- {-# LANGUAGE DeriveDataTypeable, GeneralizedNewtypeDeriving, TemplateHaskell #-} import Data.Data import Language.Haskell.TH.Syntax class Nat a class (Data a, Lift a) => ProcType a instance (Lift a, Nat s) => Lift (FSVec s a) where lift (FSVec xs) = undefined newtype Nat s => FSVec s a = FSVec {unFSVec :: [a]} deriving (Eq, Typeable, Data) -- The following line does not cause a problem in GHC 6.10 -- instance (Typeable s, Nat s, ProcType a) => ProcType (FSVec s a) ----------------------------------------------------------- works fine in ghc 6.10.4 and I get (extra stuff removed): // *Main> :i FSVec newtype (Nat s) => ... instance (Data a, Typeable s, Nat s) => Data (FSVec s a) -- Defined at ghctest.hs:16:26-29 ... // but in 6.12.2 what I get is: // *Main> :i FSVec newtype (Nat s) => ... instance (Data s, Data a, Nat s) => Data (FSVec s a) ... // So, although the last line in the above code compiles correctly in ghc 6.10.4, in 6.12.2 GHC complains with: // ghctest.hs:19:10: Could not deduce (Data s) from the context (Typeable s, Nat s, ProcType a) arising from the superclasses of an instance declaration at ghctest.hs:19:10-64 Possible fix: add (Data s) to the context of the instance declaration In the instance declaration for `ProcType (FSVec s a)' Failed, modules loaded: none. // Why are they different? Why 6.12 derives a stronger constraint? Is it a bug or it was not working correctly before? -- Hosein Attarzadeh

3 2

Cutting down GHC installation to bare minimum
by leledumbo 03 May '10

03 May '10

I notice that many of the installed libs aren't required for learning Haskell. What libs are required so I can get the bare minimum version of GHC? Also, is there any automatic way so that I don't have to manually delete the folders and edit package.conf? -- View this message in context: http://old.nabble.com/Cutting-down-GHC-installation-to-bare-minimum-tp28374… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 4

New trac policy
by Ian Lynagh 30 Apr '10

30 Apr '10

Hi all, We have made some changes to the way in which we use trac, our bug tracker. The details are all documented here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions#TheBugTracker but the highlights are below. We no longer have branch milestones (like 6.12-branch). Instead, we will make better use of the ticket priorities to differentiate tickets: * highest priority tickets are blockers for that release * high priority tickets are those that we also plan to fix before releasing * we will also try to fix as many lower priority tickets as possible Any tickets that are more than 2 major releases old (e.g. filed against 6.10, when 6.14 is about to be released) will be moved to the _|_ milestone, unless there is reason to keep them more visible (e.g. a patch attached for review, or significant support in the CC field). Thanks Ian

1 0

Default value for numCapabilities?
by Dimitry Golubovsky 30 Apr '10

30 Apr '10

Hi, As a followup to the discussion [1] about the portable way to find the number of CPUs/cores: how is the default value of numCapabilities [2] set when +RTS -N is not on the command line? Does GHC runtime figure out the number of cores itself, or it is by default 1 unless specified on the command line? Thanks. --------------------------- [1] http://haskell.org/pipermail/haskell-cafe/2010-April/076911.html [2] http://hackage.haskell.org/packages/archive/base/latest/doc/html/GHC-Conc.h… -- Dimitry Golubovsky Anywhere on the Web

5 9

ANNOUNCE: GHC version 6.12.2
by Ian Lynagh 27 Apr '10

27 Apr '10

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.12.2 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.12.1, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-2.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; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. 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

3 4

FFI calls: is it possible to allocate a small memory block on a stack?
by Denys Rtveliashvili 27 Apr '10

27 Apr '10

Good morning, Yesterday I did a few tests to measure the performance of FFI calls and found that the calls themselves are very quick (1-2 nanosecond). However, there is a kind of FFI calls when one have to allocate a temporary memory block (for a struct, or a temporary buffer). One of examples is a call to "gettimeofday" or "clock_gettime". Unfortunately, the usual way of doing it (using the "alloca" function) is quite slow (~40 nanoseconds). I was wondering, is there any way to allocate a small chunk of data on a thread's stack? That should be cheap, as by large it is just a shift of a pointer and, perhaps, a few other trivial operations. I understand that it is not safe to allocate large blocks on the stack. But we could possibly have a function similar to "alloca" which would allocate small blocks on stack and would use the "alloca" for big ones. With kind regards, Denys Rtveliashvili

7 17

Getting a GHC repository got easier: new instructions
by Simon Marlow 26 Apr '10

26 Apr '10

Our GHC repositories on darcs.haskell.org have now been upgraded to "hashed" format, with some nice consequences: - Using --lazy, getting a GHC repo over the network only takes a few minutes - No need to download tarballs any more - No complicated instructions about how to avoid case-insensitive filesystem issues on Windows and Mac The new simpler instructions are here: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources We recommend using darcs 2.4 or later for the best performance. Note that there are issues with 2.4 on Windows right now [1], so it might be handy to have an earlier version hanging around too, eg. 2.3.1. comments welcome! Cheers, Simon http://lists.osuosl.org/pipermail/darcs-users/2010-April/023736.html

2 2

three dots of :browse
by Kazu Yamamoto 26 Apr '10

26 Apr '10

Hello, If I use :browse a module with GHC 6.12, it sometimes displays garbage. Here is an example: Prelude> :browse Data.IP data AddrRange a = iproute-0.2.0:Data.IP.Range.AddrRange {addr :: a, mask :: a, mlen :: Int} (snip) data AddrRange a = iproute-0.2.0:Data.IP.Range.AddrRange {..., mask :: a, ...} data AddrRange a = iproute-0.2.0:Data.IP.Range.AddrRange {..., mlen :: Int} "..." is the garbage. Due to this, I cannot parse the output of :browse. This is not displayed with GHC 6.10. Q1) What is the intention of "..."? Q2) How to prevent it so that I can obtain output which I can parse? --Kazu

4 6