- Glasgow-haskell-users

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: Proposal for stand-alone deriving declarations?
by Simon Peyton-Jones 01 Nov '06

01 Nov '06

The thread about "stand-alone" deriving is long-ish now, so I have summarised the issues here: http://haskell.org/haskellwiki/GHC/StandAloneDeriving Perhaps those who are interested can add their thoughts? Bjorn is busy at the moment, but I think he'll get back to the implementation in a while, so now is a good time to refine the design. I've tried to note all the issues that came up by email, but I might have missed. I put it on the GHC wiki, because I'm not proposing it for Haskell'. (Someone else is free to do so, of course.) Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | John Meacham | Sent: 30 October 2006 05:17 | To: haskell-prime(a)haskell.org | Subject: Re: Proposal for stand-alone deriving declarations? | | On Fri, Oct 06, 2006 at 10:39:39AM -0500, Michael Shulman wrote: | > On 10/6/06, John Hughes <rjmh(a)cs.chalmers.se> wrote: | > >deriving (Eq Foo, Ord Foo) | > > | > >instead of | > > | > >deriving (Eq, Ord) for Foo | > | > So what does | > | > newtype Foo a = Foo a | > newtype Bar b = Bar b | > class C a b | > deriving (C (Foo a) (Bar b)) | > | > mean? I could see it meaning any or all of the following: | > | > instance (C (Foo a) b) => (C (Foo a) (Bar b)) | > instance (C a (Bar b)) => (C (Foo a) (Bar b)) | > instance (C a b) => (C (Foo a) (Bar b)) | | | this is why we should make this explicit when deriving "complex" newtype | instances, so we would write exactly the instance we want to derive: | | > deriving (C (Foo a) b) => (C (Foo a) (Bar b)) | > deriving (C a (Bar b)) => (C (Foo a) (Bar b)) | > deriving (C a b) => (C (Foo a) (Bar b)) | | respectively. | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime

1 0

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

GHC 6.6 using stale stub.c files
by Juan Carlos Arevalo Baeza 24 Oct '06

24 Oct '06

I tried recompiling a little (big?) Win32 binding library I had made, when the official one wasn't working for me. It had a bunch of generated stubs files in it (I'm not 100% sure what they are for). The problem is that, not even with -fforce-recomp (much better name, thanx!) will GHC regenerate those files (I think that's normal), but still it tries to use them if they are there. I get errors like these: Win32Test_stub.c: In function `Main_d4n0': Win32Test_stub.c:14:0: error: too few arguments to function `rts_mkPtr' Win32Test_stub.c:14:0: warning: passing arg 1 of `rts_apply' from incompatible pointer type Win32Test_stub.c:14:0: error: too few arguments to function `rts_apply' Win32Test_stub.c:14:0: warning: passing arg 1 of `rts_mkWord32' makes pointer from integer without a cast (etc, etc... lots of them). The stub file is old: C:\Documents and Settings\JCAB\My Documents\Haskell>dir Win32Test_stub.c Volume in drive C has no label. Volume Serial Number is A0CD-B8F4 Directory of C:\Documents and Settings\JCAB\My Documents\Haskell 08/18/2005 12:15 AM 637 Win32Test_stub.c 1 File(s) 637 bytes 0 Dir(s) 151,815,680,000 bytes free And yes, I'm on Windows. There are some stubs files that were regenerated: C:\Documents and Settings\JCAB\My Documents\Haskell>dir Win32\Window\Types_stub.c Volume in drive C has no label. Volume Serial Number is A0CD-B8F4 Directory of C:\Documents and Settings\JCAB\My Documents\Haskell\Win32\Window 10/22/2006 05:05 PM 717 Types_stub.c 1 File(s) 717 bytes 0 Dir(s) 151,803,375,616 bytes free So I suppose the no-longer-needed stubs files were related to the modules that made use of this Win32.Window.Types module I had here. I guess GHC doesn't need those any more, but it just tries to use any stub files it finds. It probably shouldn't use them, and it should probably even delete them, unless it generated them, at least when -fforce-recomp is specified. I'm moving on. I made a copy of all the files, so let me know if you need a repro. Deleting the stubs files fixes the problem. I haven't seen anything about this in the documentation, but maybe I just didn't look in the right places. Thanx! JCAB

2 4