- Glasgow-haskell-users

Type function under a forall type
by Stefan Holdermans 23 Jun '11

23 Jun '11

Simon, Tom, I hit this type-error message in GHC 7.0.3: Cannot deal with a type function under a forall type: forall e. El e u Is there a fundamental reason why type functions under a forall type are a bad idea? Of is it just something that hasn't been implemented/thought about yet? Cheers, Stefan

2 1

ANNOUNCE: GHC version 7.0.4
by Ian Lynagh 22 Jun '11

22 Jun '11

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.4 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 7.0.3, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/release-7-0-4.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

2 1

Re: GHC and Haskell 98
by John Lato 20 Jun '11

20 Jun '11

> > From: Bas van Dijk <v.dijk.bas(a)gmail.com> > > On 17 June 2011 16:47, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > So: ? ?Under Plan A, some Hackage packages will become un-compilable, > > ? ? ? and will require source code changes to fix them. ?I do not have > > ? ? ? ?any idea how many Hackage packages would fail in this way. > > Of the 372 direct reverse dependencies of haskell98: > > > http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/haskel… > > there are 344 which also depend on base (See http://hpaste.org/47933 > for calculating the intersection). > Is it easy to check, out of those 344, how many would build if the dependency on haskell98 were removed? I suspect it's not needed for the majority of cases. +1 for Plan A, but interested in mitigating the negative consequences. (Bas, your link doesn't work for me BTW, can't resolve the IP. May be my uni's dns cache.) John Lato

3 2

MonoLocalBinds and hoopl
by Edward Z. Yang 19 Jun '11

19 Jun '11

Hello all, Here's an experience report for porting hoopl to manage MonoLocalBinds. The Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of code writing, along the lines of this: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block where f n = FF3 $ ff n m n = FF3 $ fm n l n = FF3 $ fl n FF3 f `cat` FF3 f' = FF3 $ f' . f f, m, l and cat are polymorphic functions that are only used once in the main expression, and are floated outside to improve readability. However, when MonoLocalBinds is turned on, these all become monomorphic and the definitions fail. In contrast, this (uglier) version typechecks: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) (FF3 . fl) (\(FF3 f) (FF3 f') -> FF3 $ f' . f)) block One suggestion that I had was that we should generalize local bindings that are only used once, but Marlow pointed out that this would make the typechecker more complex and I probably would agree. As a userspace developer, I have two options: 1. Bite the bullet and put in the polymorphic type signatures (which can be quite hefty) 2. Inline the definitions 3. Move the polymorphic functions into the global namespace (3) and (2) are not so nice because it breaks the nice symmetry between these definitions, which always define f, m, l for the many, many definitions in Hoopl of this style. Cheers, Edward

6 8

ghc cyclic import error confusing
by Evan Laforge 17 Jun '11

17 Jun '11

I've found ghc's cyclic import error to be rather confusing, and I finally took the time to understand why. Here's an example: Module imports form a cycle for modules: Cmd.Cmd (./Cmd/Cmd.hs) imports: Perform.Midi.Instrument Instrument.MidiDb Instrument.Db Perform.Midi.Instrument (./Perform/Midi/Instrument.hs) imports: Cmd.Cmd Instrument.MidiDb (./Instrument/MidiDb.hs) imports: Perform.Midi.Instrument Instrument.Db (./Instrument/Db.hs) imports: Instrument.Search Instrument.MidiDb Perform.Midi.Instrument Instrument.Search (./Instrument/Search.hs) imports: Instrument.MidiDb Perform.Midi.Instrument It seems to be in a strange order and mentions extraneous modules. I would find this much easier to read: Perform.Midi.Instrument -> Cmd.Cmd -> Instrument.MidiDb -> Perform.Midi.Instrument Instead, the order goes Cmd.Cmd -> Instrument.MidiDb, and then goes backwards to Perform.Midi.Instrument -> Cmd.Cmd. Then it goes forward again to Instrument.MidiDb -> Perform.Midi.Instrument. So the order makes you jump around if you want to trace the import chain. The duplicated module that joins the cycle is not visually highlighted. Whats more, it further confuses the eye by merging in multiple loops. I suppose it could be useful to include additional loops, but I would find it easier to read if they were included on their own line, such as: Cmd.Cmd -> Instrument.Db -> Instrument.Search -> Perform.Midi.Instrument -> Cmd.Cmd However, I think probably the shortest loop is the most interesting one, and if there are multiple shortest loops, simply picking one randomly is likely to be sufficient. Thoughts?

5 5

URL for GHC 7.0.3
by Simon Sin 16 Jun '11

16 Jun '11

hi, GHC freaks, I tried to set up GHCi 7.0.3 and the latest haskell-platform on my new buntu 11.04 installation. I can successfully did it for 6.10.3 by following the instruction from one web post (Spork Code). Then I following the URL given by another web post to 'wget' the 7.0.3. but get an error 404 file not found. Can anybody point me to the correct URL to get 7.0.3 tar.bz2 ? Thank you very much. Simon.

3 3

Wiki page about new memcpy/memmove/memset primops need a home
by Johan Tibell 14 Jun '11

14 Jun '11

Hi, I intend to write a short wiki page explaining the design and use of the new memcpy/memmove/memset primops we added recently. Where would be a good place to put such a page? Cheers, Johan

3 3

Re: How to install GhC on a Mac without registering?
by Malcolm Wallace 14 Jun '11

14 Jun '11

On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: > I would be fantastic if XCode wasn't a dependency. ... > > Not to detract at all from the work of the wonderful GHC and Haskell > Platform contributors in any way. For me it would just make it that > much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm

10 17

Re: How to install GhC on a Mac without registering?
by Lars Viklund 10 Jun '11

10 Jun '11

On Fri, Jun 10, 2011 at 11:31:01PM +1000, Manuel M T Chakravarty wrote: > Lars Viklund: > > On Fri, Jun 10, 2011 at 09:24:41PM +1000, Manuel M T Chakravarty wrote: > >> Well, then get the DVDs bundled with your Mac and install Xcode from those, or sign up at developer.apple.com and get it there. BTW, Mac users (and esp devs) upgrade very quickly, much faster than, say, Windows users. > > > > I disagree with the assumption that OS X people are quick to upgrade. > > The last set of figures I saw on adoption were something along the lines > > of 15% on 10.6, with almost a third of the users on 10.4 and below, > > taken from some article I read the other week on the rising wave of OS X > > viruses and countermeasures. > > Those numbers sound completely wrong and I'd like to see a credible source before I believe them. As just one data point on Snow Leopard adoption, have a look at > > http://daringfireball.net/2009/09/snow_leopard_adoption_rate > > I would say that readers of Daring Fireball are fairly tech savvy people with an above average percentage of developers. But consider this, > > "it took about five days for 10.6 to pass 10.5" > > Five days from the release of the OS for 50% of the DF readers to upgrade to Snow Leopard. My browser history had it, with what I assume is a much better sample size than "the DF readers", and being much more current: http://www.zdnet.com/blog/hardware/apples-mac-defender-update-allows-users-… Re-visiting the URI, I notice that the low percentages I vaguely recalled were total OS marketshare, not OS X alone. Normalizing 10.6 v. 10.5 v. 10.4 yields this, which aligns with data mentioned in the thread: * 10.6 - 68.6% * 10.5 - 24.4% * 10.4 - 7.0% That's a solid 30% or so not on current OS X. I do have a problem with your "developers are more up to date" argument, as everyone who wants to build any package with native bits needs a toolchain installed. There's a fair amount of such packages on Hackage. This counter-argument is of course void and null if there's popular sane ways to deploy binary application bundles on OS X akin to Bamse, but to my knowledge no such beast exists. -- Lars Viklund | zao(a)acc.umu.se

1 0

Using CPP in Cmm
by Johan Tibell 09 Jun '11

09 Jun '11

Hi, I'm trying to write a test case to make sure memset gets unrolled correctly by the backend. Unrolling only happens when the alignment and size is statically known so writing a simple Cmm loop that calls memset won't work as the sizes won't be statically known. I want to test memset with a large (e.g. 10-20) different variations of alignments and sizes and I don't want to cut-n-paste large chunks of code so I tried the following (best viewed with a fixed-width font): #define TEST_MEMSET(ALIGN,SIZE) \ W_ size, src, dst, off, alignV, set; \ bits8 set8; \ \ // Need two versions as memset takes a word for historical reasons \ // but really its a bits8. We check that setting has ben done \ // correctly at the bits8 level, so need bits8 version for \ // checking. \ set = 4; \ set8 = 4::bits8; \ \ size = SIZE; \ alignV = ALIGN; \ ("ptr" src) = foreign "C" malloc(size); \ ("ptr" dst) = foreign "C" malloc(size); \ prim %memset(src "ptr", set, size, alignV) []; \ \ // Check memset worked \ off = 0; \ while1: \ if (off == size) { \ goto while1_end; \ } \ if (bits8[src + off] != set8) { \ foreign "C" printf(memsetErr "ptr") []; \ goto while1_end; \ } \ off = off + 1; \ goto while1; \ while1_end: \ foreign "C" free(src); \ foreign "C" free(dst); unrollintrinTest { // Test many different combinations here. TEST_MEMSET(8,8); TEST_MEMSET(4,8); jump %ENTRY_CODE(Sp(0)); } This seems to work (i.e. the test passes) but it shouldn't! I'd expect the fact that we generate several labels (and temp registers) with the same name to lead to problems, but it doesn't seem to. I initially tried to use the CPP ## string concatenation operator to create unique names (tedious, but works) but GHC runs CPP in traditional mode so that doesn't work. I also tried to introduce local {} blocks in the Cmm to deal with the scoping of identifiers (like you would in C) but that's not supported. Any idea of how I can generate the same piece of Cmm code (that contains labels and locally defined identifiers) multiple times without name capturing? Cheers, Johan

2 1