October 2006 - Glasgow-haskell-users

moving to ghc-6.6
by Johannes Waldmann 02 Nov '06

02 Nov '06

Hello. I just move a larger project to ghc-6.6 (from 6.4) http://dfa.imn.htwk-leipzig.de/auto/ (ca. 1000 modules) I had to modify my sources in several places. Perhaps the following list of observations is useful. tools: cabal/ghc work nicely, including building for profiling and haddockumentation. (I'm still missing cabal support for building docs that I want to access not via the file system but via a web server.) when "ghc --make" finds a source file that starts wrongly (e. g. "modul Foo" instead of "module Foo") (might occur from unobserved CVS merge conflicts) it just says <no location info>: file name does not match module name `Main' and it is quite impossible to find out which file is to blame (even "ghc -v" does not give any information?) type system: In some places I found it convenient to write type decls like foo ( x :: a ) ( y :: [ b ] ) = ... because this gave me at least some kind of documentation while I was too lazy to figure out all the type class requirements that I would need for a full signature. This is now impossible (a and b can no longer be declared by the line above?). But on the other hand this is more a question of coding style, not of compilation. Still the above method gave me the easiest way of getting some programs to compile. I cannot just remove all type sigs because then parts of the program might be ambiguous. To disambiguate, I am now forced to be more verbose. (Which may be a good thing.) Sometimes the type class restrictions in my code are larger than the actual program ... Yes, I introduce "constraint collection classes", e.g. http://141.57.11.163/cgi-bin/cvsweb/box/src/Rewriting/Approximation/Genet.h… I guess I have too much overlapping instances in my code already, and now ghc seems to enforce that this be declared earlier (at the class definition, not usage)? the "coverage condition not satisfied" error message (with functional dependencies) should include a hint that "-fallow-undecidable-instances" might help. library changes: Network.CGI is new, but we have Network.CGI.Compat. Which however refers to Text.XHtml, not Text.Html, so I had to change these imports as well. source encoding: it is annoying that ghc only accepts UTF-8 now. sure I can use "iconv" but I rather not touch my sources at all. with "javac", I can just say "-encoding latin1". Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

ANNOUNCE: GHC version 6.6
by Ian Lynagh 01 Nov '06

01 Nov '06

=========================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.6 =========================================================== The GHC Team is pleased to announce a new release of GHC. There have been many changes since the 6.4.2 release. For details, see the release notes here: http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.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://www.haskell.org/ghc/docs/latest/html/building/building-guide.html 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

instance Data (Complex a)
by Chad Scherrer 01 Nov '06

01 Nov '06

I was playing around with the Data.Generics stuff, and I'm getting an error that says No instance for (Data (Complex Double)) Looking at the source for Data.Complex, I see it is an instance of Typeable, but not of Data. Is there a reason not to add "deriving Data" on the end of this? Thanks, Chad

2 1

RE: [Hugs-users] Record puns, time for removal?
by Simon Peyton-Jones 01 Nov '06

01 Nov '06

| There was some discussion on the haskell' list about bring back | record puns, which were once in ghc. | | Record punning would have been very helpful on one of my recent | projects, where I had some large arrays of statically initialized | records. | The longFieldSelectorNamesToAvoidNamespaceClashes are just | noise is such a case. I always thought it was a mistake to remove record puns in H98. I would not be against re-introducing them into GHC, since they appear to remain in Hugs and are in Yhc. Simon

7 10

OpenGL failing with Mac Intel 6.6 distribution
by Deborah Goldsmith 31 Oct '06

31 Oct '06

I'm attempting to build frag on Mac OS X Intel with the 6.6 distribution, and I hit the following: /tmp/ghc25850_0/ghc25850_0.hc:5:22: error: HsOpenGL.h: No such file or directory A comparison of the C include directories for 6.6 and a recent 6.5 build gives: $ diff -r /usr/local/lib/ghc-6.5.20061008/include/ /usr/local/lib/ ghc-6.6/include/ Only in /usr/local/lib/ghc-6.5.20061008/include/: HsOpenGL.h Only in /usr/local/lib/ghc-6.5.20061008/include/: HsOpenGLExt.h Only in /usr/local/lib/ghc-6.5.20061008/include/: HsOpenGLTypes.h Only in /usr/local/lib/ghc-6.6/include/: HsReadline.h Only in /usr/local/lib/ghc-6.6/include/: HsReadlineConfig.h diff -r /usr/local/lib/ghc-6.5.20061008/include/ghcautoconf.h /usr/ local/lib/ghc-6.6/include/ghcautoconf.h 130c130 < #define HAVE_LIBIBERTY 1 --- > /* #undef HAVE_LIBIBERTY */ Is the fact that HSOpenGL*.h is missing in 6.6 expected? Thanks, Deborah

4 7

improving error messages
by Bulat Ziganshin 30 Oct '06

30 Oct '06

Hello glasgow-haskell-users, as you may remember, in GHC survey awkward error messages was named as one of most serious GHC drawbacks. i propose to start collecting examples of bad error messages together with what we want to see in these cases. as first contribution, i've added this text as http://hackage.haskell.org/trac/ghc/ticket/956 the following program main = do putChar 'a' putChar makes this error message:: Couldn't match expected type `IO' against inferred type `(->) Char' Probable cause: `putChar' is applied to too few arguments In the expression: putChar while the 'probable cause' is very helpful, the error message by itself is hard to understand for novices. i propose in these cases to work against known value types. in this case, we know that 'putChar' has type 'Char -> IO ()' and GHC may report smth like this: 'putChar': expression of type 'Char -> IO ()' used in context that requires expression of 'IO ()' type Probably, you've omitted parameter of type 'Char' to this expression comparing this with existing message shows that may be improved: 1) for me, it's still hard to understand what is "expected" and "inferred" means. i guess that for true beginners it's even harder. i prefer to see something more English and less Mathematic - it will be very helpful 2) instead of obscure 'IO' and `(->) Char' types, i strongly prefer to see more pragmatic 'IO ()' and 'Char -> IO ()' ones 3) 'Probable cause' may be more pleasant by telling position and type of skipped argument(s) my second example is almost the same :) main = do putChar putChar 'a' in this case error message is even worser: Couldn't match expected type `(->) Char' against inferred type `IO' Probable cause: `putChar' is applied to too many arguments In the expression: putChar 'a' afaiu, here GHC thought that putChar should have 'IO ()' type. or, it may think that operations in this monad has type 'Char -> IO ()'. anyway, it will be great if GHC will know that operations in monad usually has type 'IO a' or 'm a' and try to use this heuristic when dealing with such errors (different types of statements in 'do' block) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

GHC 6.6 for OS X using MacPorts
by Gregory Wright 28 Oct '06

28 Oct '06

Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC gwright(a)antiope.com

3 8

OS X - Haskell to Objective-C Binding on GHC 6.6
by Charlie Conklin 26 Oct '06

26 Oct '06

Is anyone out there running OS X and using HOC and GHC 6.6? I took the latest from cvs and got some way toward getting it to compile by changing the code to: 1. reflect changes regarding packages, i.e. adding -package-name to the pertinent makefiles, and accommodating the changed signature of Language.Haskell.TH.Syntax mkNameG_v and mkNameG_tc 2. replacing the obsolete names used from Data.Set which have been removed from GHC 6.6. At that point HOC was able to get to the point where it parses the ObjC headers, but it then choked on compiling the generated .hs files, some of which seem to have invalid constructions like: -- enum definitions $(declareAnonymousCEnum [("NSFileNoSuchFileError", 4),("NSFileLockingError", 255),("NSFileReadUnknownError", 256),("NSFileReadNoPermissionError", 257),("NSFileReadInvalidFileNameError", 25,("NSFileReadCorruptFileError", 259),("NSFileReadNoSuchFileError", 260),("NSFileReadInapplicableStringEncodingError", 261),("NSFileReadUnsupportedSchemeError", 262),("NSFileWriteUnknownError", 512),("NSFileWriteNoPermissionError", 513),("NSFileWriteInvalidFileNameError", 514),("NSFileWriteInapplicableStringEncodingError", 517),("NSFileWriteUnsupportedSchemeError", 51,("NSFileWriteOutOfSpaceError", 640),("NSKeyValueValidationError", 1024),("NSFormattingError", 204,("NSUserCancelledError", 3072),("NSFileErrorMinimum", 0),("NSFileErrorMaximum", 1023),("NSValidationErrorMinimum", 1024),("NSValidationErrorMaximum", 2047),("NSFormattingErrorMinimum", 204,("NSFormattingErrorMaximum", 2559)]) I'm a complete beginner to Hasell, and at this point I'm a bit stuck. Any help would be much appreciated! Cheers, - Charlie

3 3

Difference between errorCalls and userErrors
by Andreas Marth 26 Oct '06

26 Oct '06

Hi! In module Control.Exception there are the exception predicates errorCalls and userErrors defined. Is there any difference between them? Which one? Thanks for any explanations, and maybe it should be documented in more detail? Kind regards, Andreas

2 1

GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
by Michael Marte 25 Oct '06

25 Oct '06

Hello *, before filing a bug report, I want others to comment on my problem. Maybe it's my fault, not ghc's. I wrapped up some Haskell modules in a Win32 DLL. Loading the DLL dynamically (with LoadLibrary) works fine. However, whether I actually use the library or not, the program (an application with MFC GUI) crashes upon termination. To find the reason for the crash, I added a new function for unloading the DLL using FreeLibrary. FreeLibrary works fine, however the program crashes when it returns to the main event loop. Interestingly, when I reload the library (FreeLibrary followed by LoadLibrary) the program continues working. However, every reload cycle causes the virtual size of the process to increase by about 300K and the fourth reload fails with the error message "getMBlock: VirtualAlloc failed with: 8" (appears in a message window) accompanied by many repetitions of the message "Timer proc: wait failed -- error code: 6" (appears on stderr) and followed by the message "getMBlocks: misaligned block returned" (again in a message window). Then the programm crashes. Development takes place on Windows XP Professional using MS Visual Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side to the Haskell heap. I build the DLL using the command ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o dllMain.c dllMain.c looks as follows: #include <windows.h> #include <Rts.h> extern void __stginit_EUzu3820zu85(void); static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain(HANDLE hModule, DWORD reason, void* reserved) { if (reason == DLL_PROCESS_ATTACH) { /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */ startupHaskell(1, args, __stginit_Foo); return TRUE; } else if (reason == DLL_PROCESS_DETACH) { shutdownHaskell(); } return TRUE; } I played around with hs_exit instead of shutdownHaskell, I moved initialization and clean-up from DllMain to my library loader, nothing helps. Even doing no clean-up whatsoever does not change the behaviour. Any ideas? Michael

7 16