- Glasgow-haskell-users

RE: [Haskell-cafe] Impredicative Types
by Simon Peyton-Jones 19 Nov '10

19 Nov '10

Yes, impredicative types are still in, but in a simpler form than before, along the lines of QML http://research.microsoft.com/en-us/um/people/crusso/qml/ I have been too busy with getting the new type checker working to describe or document it. Notably, I have not yet added syntax for QML's rigid type annotations, which leads to a loss of expressive power. too much to do! Bottom line: if you are interested in impredicative polymorphism, let me know. A good way to do so would be to register your interest on http://hackage.haskell.org/trac/ghc/ticket/4295 Just add your email address to the cc list, *and* write a comment giving an example of how you are using impredicative poly, and pointing to any further info. That'll help motivate me to do the remaining work! Thanks Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] | On Behalf Of Gregory Crosswhite | Sent: 19 November 2010 19:23 | To: Haskell Cafe | Subject: [Haskell-cafe] Impredicative Types | | Hey everyone! I haven't had a chance to try out GHC 7 myself, but I saw | in the documentation that Impredicative Types are still supported. Is | this true? I thought that they were on their way out because they | overcomplicated type checking; has this plan been changed? | | Cheers, | Greg | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Using the GHC API: pretty printing with qualified names
by JP Moresmau 19 Nov '10

19 Nov '10

Hello, I'm the maintainer for EclipseFP, which involves using the scion library and the GHC API to provide IDE functionality. I have a little issue that no doubt stems from me not understanding the GHC API well, and I would be grateful for any light on the matter. I'm trying to give the user the possibility to jump to the definition of a symbol in the source file. You click on the name of a function and you're send to the module where it's defined. So I have an AST, and somewhere down the line I have an Id object representing that function call. Then I just use ppr alwaysQualify id to get the fully qualified name of the function, and I can then use the module name to retrieve the source file etc. This works well in cases, but not in others. It will sound silly to the gurus on the list, but it's when the function has generics that it doesn't work. So a function with a type class in its type signature will never be printed qualified. It kinda like makes sense because I suppose some work has been done so that it represents the function with proper types, etc., but how can I get back to the original Id? How can I get back from that unqualified Id to the qualified Id representing the function in the original module? I've been looking round Name and OccName and all that but I'm not sure really what I'm looking for. Hope I'm making sense!! Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/

5 9

List vs Data.List
by Serge D. Mechveliani 18 Nov '10

18 Nov '10

In ghc-7.0.1, to import `partition', it is sufficient the line import List (partition), but to import `intercalate', it is needed import Data.List (intercalate). Does Haskell-2010 differ between List and Data.List import? Thank you in advance for explanation, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Non-exhaustive pattern match(es) warning in lambda functions
by Mitar 18 Nov '10

18 Nov '10

Hi! Why GHC does not warn (with -Wall) about non-exhaustive pattern match(es) warning in lambda functions? For example, this code: data Foo = Bar | Baz test1 :: Foo -> IO () test1 Bar = return () -- Pattern match(es) are non-exhaustive warning, OK test2 :: Foo -> IO () test2 = \Bar -> return () -- No pattern match(es) are non-exhaustive, BAD I think it would be quite useful to also catch such situations and issue a warning. Mitar

4 9

Terminate unused worker threads
by Edward Z. Yang 18 Nov '10

18 Nov '10

I finally got some spare time to do some GHC hacking, and after feeling my way around http://hackage.haskell.org/trac/ghc/ticket/4262 I came up with the following patch, which appears to work (that is, bound the number of worker threads hanging around after FFI calls): diff -rN -u old-ghc-clean/rts/Capability.c new-ghc-clean/rts/Capability.c --- old-ghc-clean/rts/Capability.c 2010-11-07 14:21:53.000000000 +0000 +++ new-ghc-clean/rts/Capability.c 2010-11-07 14:21:54.000000000 +0000 @@ -461,6 +461,16 @@ // This happens when the system is shutting down (see // Schedule.c:workerStart()). if (!isBoundTask(task) && !task->stopped) { + int i; + Task *t = cap->spare_workers; + // arbitrarily picked six spare workers as a good number + for (i = 1; t != NULL && i < 6; t = t->next, i++) {} + if (i >= 6) { + debugTrace(DEBUG_sched, "Lots of spare workers hanging around, terminating this thread"); + releaseCapability_(cap,rtsFalse); + RELEASE_LOCK(&cap->lock); + pthread_exit(NULL); + } task->next = cap->spare_workers; cap->spare_workers = task; } There are a few obvious questions with this patch: - We're doing a walk (albeit constant bounded) of the spare workers list; if we're actually not going to ever exceed X number maybe we should use a circular buffer or store the number of items in the queue. - It's not 100% clear to me if I've done enough cleanup (i.e. maybe other locks to release, items to free, etc?) - Of course, POSIX only, for now. Fortunately Windows is nice enough to give us ExitThread() so porting should be not a problem. Edward

3 5

Re: Proposal: Require OverlappingInstances for the most specific instance only
by Christian Höner zu Siederdissen 16 Nov '10

16 Nov '10

The change should not affect working programs, as it just allows you to define further places where you say that you want an overlapping instance. Gruss, Christian * Serge D. Mechveliani <mechvel(a)botik.ru> [16.11.2010 16:47]: > On Tue, Oct 26, 2010 at 09:41:58PM +0200, John Smith wrote: > > In the case of overlapping instance declarations, GHC currently requires > > the less specific instance to be compiled with OverlappingInstances for the > > more specific instance to be usable. This means that, for example, if you > > write > > > > type ChessBoard = Array (Int,Int) Piece > > > > there is no way to > > > > instance Show ChessBoard where > > show board = ... > > > > because Array is already an instance of Show, and was not compiled with > > OverlappingInstances. > > > > http://hackage.haskell.org/trac/ghc/ticket/3877 requests that > > OverlappingInstances be required for only the most specific instance > > declarations, as suggested in the documentation. "Perhaps the rule should > > instead say that the overlapping instance declaration should be compiled in > > this way, rather than the overlapped one ... We are interested to receive > > feedback on these points." > > > > SPJ offered to make this change, if the list users agree. (See comment 6.) > > Proposed deadline for discussion is 16th November. > > > > I always expected that such programs as above must be valid. > On the other hand, I do not understand these possible ways of compilation, > these words about "compiled in this way, rather than the overlapped one". > Now, as I already have overlapping instances work in my programs, for a > long time, it is difficult for me to predict the consequences of the > change. > Can the team issue the corresponding GHC pre-release for testing, > without making a decision for future before the users report their > impression? > > With kind regards, > > ----------------- > Serge Mechveliani > mechvel(a)botik.ru > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Proposal: Require OverlappingInstances for the most specific instance only
by John Smith 16 Nov '10

16 Nov '10

In the case of overlapping instance declarations, GHC currently requires the less specific instance to be compiled with OverlappingInstances for the more specific instance to be usable. This means that, for example, if you write type ChessBoard = Array (Int,Int) Piece there is no way to instance Show ChessBoard where show board = ... because Array is already an instance of Show, and was not compiled with OverlappingInstances. http://hackage.haskell.org/trac/ghc/ticket/3877 requests that OverlappingInstances be required for only the most specific instance declarations, as suggested in the documentation. "Perhaps the rule should instead say that the overlapping instance declaration should be compiled in this way, rather than the overlapped one ... We are interested to receive feedback on these points." SPJ offered to make this change, if the list users agree. (See comment 6.) Proposed deadline for discussion is 16th November.

2 1

multiple module program fails compile
by Larry Evans 15 Nov '10

15 Nov '10

The attached program fails to compile despite it being a close copy of that shown in the Reference: comments. The ghci invocation results in: ================================ ~/prog_dev/haskell/my-code $ ghci Modules.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Test ( Modules.hs, interpreted ) Modules.hs:12:0: parse error on input `module' Failed, modules loaded: none. Prelude> :q Leaving GHCi. ================================== What should change to allow compilation? TIA. -Larry

3 2

Can't pull http://darcs.haskell.org/ghc
by David Fox 15 Nov '10

15 Nov '10

I can neither darcs pull nor darcs get the repository at http://darcs.haskell.org/ghc - it just hangs indefinitely. Anyone else having this problem? -david

2 1

6.12.3: hs_add_root crashes
by Bulat Ziganshin 15 Nov '10

15 Nov '10

Hello , ghc 6.12.3. i use the following code to initialize my haskell dll: extern "C" { #include "HsFFI.h" void __stginit_Main(); void haskell_init (void) { static bool initialized = FALSE; if (!initialized) { initialized = TRUE; hs_init(NULL, NULL); hs_add_root(__stginit_Main); } } } but it crashes on hs_add_root call. what may be source of problem? without hs_add_root, it works ok, but crashes on multiple calls from C to haskell functions, probably due to GC of "unused" code :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 1