May 2009 - 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

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 22 Sep '09

22 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

8 13

--out-implib when linking shared libraries
by Neil Mitchell 17 Jun '09

17 Jun '09

Hi, I've just built a Haskell dll on Windows. As part of the process it generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags passed to ld I see --out-implib=foo.dll.a. What is the purpose of the .a file? What might it be needed for? Is it possible to suppress it? I could easily be building 100 of these things and 4Gb of disk for unused files is a little painful. Thanks Neil

3 5

can't run Grapefruit
by Dean Herington 16 Jun '09

16 Jun '09

I'm trying to give Grapefruit a try. I installed it as described in section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I tried to run the Simple.hs example, I got the problem shown below. Any ideas? My machine is running Windows XP Pro 2002 SP3. TIA Dean GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple> run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.1 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package filepath-1.1.0.1 ... linking ... done. Loading package directory-1.0.0.2 ... linking ... done. Loading package process-1.0.1.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could not load DLL)

4 4

6.10.4 plans
by Ian Lynagh 09 Jun '09

09 Jun '09

Hi all, Unfortunately, since the release of 6.10.3, still more problems have come to light in the 6.10 branch. We are therefore planning to do a 6.10.4 release. For 6.10.4, we will only consider fixes for serious bugs that cannot be easily worked around. So far, we plan to look into: * One of the patches in 6.10.2 introduced a problem where mkWeakForeignEnv# could segfault (already fixed) * readMutVar# is inlined/duplicated http://hackage.haskell.org/trac/ghc/ticket/3207 (already fixed, patch waiting to be merged) * "Permission denied" errors on Windows: http://hackage.haskell.org/trac/ghc/ticket/3231 http://hackage.haskell.org/trac/ghc/ticket/2924 * Some ghci tests fail with hLookAhead errors. We would like to at least understand exactly what is going on here. If you find any other bugs that you think we should look into for 6.10.4, please let us know. We don't have any plans for when to do the release yet, but we would like to be confident that we have waited long enough for any other bugs to surface, and to have time for 6.10.4 to be well-tested. Thanks Ian

3 4

Should exhaustiveness testing be on by default?
by Don Stewart 07 Jun '09

07 Jun '09

I'm not sure I'd want -Wall on by default (though being -Wall clean is very good). But exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds. http://ocaml.janestreet.com/?q=node/64 Ron's also wondering why exhaustive pattern checking isn't on ? Anyone know why it isn't the default? -- Don

12 41

Problem with profiling
by Marco Túlio Gontijo e Silva 03 Jun '09

03 Jun '09

Hello, recently there was a thread about a problem in profiling in gtk2hs-users, and it was menitoned that this could be a GHC6 bug. The problem is described in http://sourceforge.net/mailarchive/forum.php?thread_name=1242762143.18742.2… . Do you think this is a gtk2hs specific problem, or is it something about GHC? Greetings. -- marcot http://marcot.iaaeee.org/

3 3

ghc - force library search order
by John Lask 02 Jun '09

02 Jun '09

----- Original Message ----- From: "Duncan Coutts" <duncan.coutts(a)worc.ox.ac.uk> To: "John Lask" <jvlask(a)hotmail.com> Sent: Friday, May 29, 2009 8:09 PM Subject: Re: [Haskell-cafe] ghc - force library search order > On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: >> I need to force a library to be searched for unresolved symbols after all >> other libraries have been searched, and I would rather not resort to >> constructing the linker command line directly. Is there a way to do this? >> >> i.e. I want for example -lfoo to appear after all other haskell libraries >> and before system libraries (for example -lmsvcrt) once ghc has >> constructed >> the link command. i.e. how is it possible to coerce ghc into respecting >> dependencies between the libraries. GHC does a good job in general with >> native libraries, but there are allways corner cases. >> >> I have a feeling this is not possible, but it dosn't hurt to ask. > > If you don't get a reply then ask on the ghc users mailing list. > > Duncan > >

2 3

mtl and network packages in GHC 6.10.3.*
by Neil Mitchell 30 May '09

30 May '09

Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil

6 7

draft proposal for relative paths in installed package descriptions
by Duncan Coutts 29 May '09

29 May '09

All, This is a draft proposal for a common mechanism for implementing relative paths in installed package descriptions. Comments and feedback are welcome. I'm cc'ing this to the cabal and ghc-users lists but let's keep the discussion on the libraries list. There has been some discussion of this issue on the cabal and ghc-users list, but it's a relatively long thread and the idea has evolved somewhat so this is an attempt to present the proposal clearly. Proposal ======== This proposal is an extension to the Cabal spec section 3 http://haskell.org/cabal/proposal/x272.html Motivation ---------- Being able to have relative paths in the installed package description is useful as it makes it possible to construct relocatable (prefix-independent) package installations. This is useful when distributing compilers along with packages and there may be other uses. This proposal does not require that all paths are relative. It is still perfectly ok to use absolute paths where appropriate. It just adds an option to use relative paths. The aim is for a single simple specification that any compiler can implement and have the tools work uniformly, rather than ad-hoc implementations for each compiler. Details ------- In the installed package description, we will allow paths that begin with the variables ${pkgroot} or ${pkgrooturl}. For example: library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 They may only appear at the beginning of the paths and must be followed by a directory separator (platform-dependent '/' or '\'). This is because the vars refer to a directory so it does not make sense to construct extensions like ${pkgroot}blah. The use of '{}' is required and is to avoid any ambiguity (especially since the string "$pkgrooturl" is otherwise an extension of "$pkgroot"). Directly relative file paths like "blah" or "./blah" are not allowed. Fields containing paths must be absolute or begin with ${pkgroot}. Field containing urls must be absolute or begin with ${pkgrooturl}. The var ${pkgroot} is to be interpreted as the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is the usual system-dependent filepath syntax, e.g. windows: c:\ghc\ghc-6.12.1 unix: /opt/ghc-6.12.1 The var ${pkgrooturl} is to be interpreted as a url representation of the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is as a valid file url including the file:// prefix e.g. windows: file:///c:/ghc/ghc-6.12.1 unix: file:///opt/ghc-6.12.1 This is similar to how relative paths in .cabal files are interpreted relative to the directory containing the .cabal file, however in this case we mark relative paths more explicitly using a variable. So in the original example library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 If we assume this installed package description is at c:\ghc\ghc-6.12.1 \package.conf on windows or /opt/ghc-6.12.1/package.conf on unix then the compiler and other tools would interpret these as library-dirs: c:\ghc\ghc-6.12.1/foo-1.0 haddock-html: file:///c:/ghc/ghc-6.12.1/doc/foo-1.0 or on unix: library-dirs: /opt/ghc-6.12.1/foo-1.0 haddock-html: file:///opt/ghc-6.12.1/doc/foo-1.0 Tools ----- Tools which process the installed package description format will be expected to interpret these relative paths. This requires that they can discover the path for the ${pkgroot}. How they discover this is dependent on the Haskell implementation. Some implementations use separate files for each installed package description, some embed them in library package files, some use databases of installed package descriptions. Haskell implementations should provide a mechanism to discover the path for an installed package description. Duncan

1 0