- Glasgow-haskell-users

flexible contexts and context reduction
by Ganesh Sittampalam 27 Mar '08

27 Mar '08

Hi, I'm a bit confused about why the following program doesn't compile (in any of 6.6.1, 6.8.1 and 6.9.20080316). Shouldn't the Ord (a, b) context be reduced? Cheers, Ganesh {-# LANGUAGE FlexibleContexts #-} module Test2 where foo :: Ord (a, b) => (a, b) -> (a, b) foo = bar bar :: (Ord a, Ord b) => (a, b) -> (a, b) bar = id

4 5

Inconsistent .hi files with associated types?
by Niklas Broberg 25 Mar '08

25 Mar '08

Hi all, I'm getting a weird warning/error message from GHC that I don't understand: ===================== $ runhaskell Setup build Preprocessing library hsp-hjscript-0.3.4... Building hsp-hjscript-0.3.4... [1 of 1] Compiling HSP.HJScript ( HSP/HJScript.hs, dist\build/HSP/HJScript.o ) C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f35 Unfolding of HSP.Monad.$f35: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R32XML Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi Declaration for $f6 Unfolding of HSP.Monad.$f6: Can't find interface-file declaration for type constructor or class HSP.Monad.:CoF:R5SetResult Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error C:\Program\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShsp-hjscript-0.3.4.a ===================== Can anyone explain to me what's up here? I have no .hi-boot files., and -ddump-if-trace gives no further info. Both XML and SetResult are associated types. Both of the instances in question are defined in a different package, which compiles without error. The classes that define the types are in yet another package, which also compiles without error. I note that the compilation of the package continues, so I suppose these are error messages only, even though they sound quite fatal. But what effect will this have on programs using the module? Cheers, /Niklas

2 1

Announce: HXQ: A Compiler from XQuery to Haskell
by Leonidas Fegaras 24 Mar '08

24 Mar '08

I would like to announce the release of HXQ: A Compiler from XQuery to Haskell. HXQ is a fast and space-efficient translator from XQuery (the standard query language for XML) to embedded Haskell code. The translation is based on Haskell templates. HXQ takes full advantage of Haskell's lazy evaluation to keep in memory only those parts of XML data needed at each point of evaluation, thus performing stream-based evaluation. This results to an implementation that is as fast and space-efficient as any stream-based implementation based on SAX filters or finite state machines. Furthermore, the coding is far simpler and extensible since its based on XML trees, rather than SAX events. For example, an XQuery against the DBLP XML database (420MB) runs in 1.5 minutes. You can get more information at: http://lambda.uta.edu/HXQ/ Leonidas Fegaras U. of Texas at Arlington http://lambda.uta.edu/

2 1

Scripting an application in haskell: howto expose application api ?
by Marc Weber 24 Mar '08

24 Mar '08

Hi, I'd like to add haskell scripting (ghc) support to vim. Passing the cmd to a .hsc module already works fine. But I can't imagine yet how to expose vim functions to the session started with newSession from the GHC API. Of course one way to go is interprocess communication (opening kind of pipe sending events/ commands replies..) But maybe you can think of someting easier ? Sincerly Marc Weber

2 1

Re: [Haskell-cafe] Type checking of partial programs
by ac 23 Mar '08

23 Mar '08

So a number of people responded with various ways this is already possible. Of course GHC can already do this... it's type inference. The part I'm interested in working on is exposing the functionality in GHC's API to make this as easy as possible. -Abram

1 0

RE: Optimization beyond the Module Border
by Matthew Pocock 21 Mar '08

21 Mar '08

> | > I'd be interested in any progress here -- we noticed issues with > | > optimisations in the stream fusion package across module boundaries > | > that we never tracked down. If there's some key things not firing, > | > that would be good to know. > | > | I suspect that if all modules are compiled -O0, then you recompile one > | module with -O2, high up in the dependency graph (i.e. it depends on > | many lower-level modules), plus all things that in turn depend on it > | (--make), you will not get the good performance you expect. None of the > | lower-level functions will have exported inlinings or fusion rules into > | the interface file. _All_ modules must be recompiled with -O2, > | especially the bottom of the dependency chain, to get the best benefit > | from optimisation. > > Absolutely correct. > > Should this be better documented? If so, would someone like to think > where in GHC's user manual they would have looked (or did look), and send > me some text that would have helped them, had it been there? As it were. > > Simon Would it be possible for the compiler to say something like: "You are applying level 2 optimization but some dependencies where compiled without optimization enabled. To get full optimization, consider recompiling x,y,z with -O2" - at least this would give us a fighting chance to 'fix' things. Matthew > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 1

Type checking of partial programs
by ac 21 Mar '08

21 Mar '08

Is anybody interested in working on this? This is a project I've been interested in for some time, but recognize I probably need some guidance before I go off and start hacking on it. As dcoutts pointed out on #haskell-soc, this may be of particular interest to people working on yi and HaRe. Other interesting and related projects include parsing partial programs to insert "placeholders" in appropriate places. An example of a partial program could be: foo :: [Foo] -> <placeholder 1> foo xs = map <placeholder 2> xs What are the possible type signatures for placeholder 1 and the possible expressions for placeholder 2? I would like to stir up a discussion about this, and eventually write some useful code. -Abram

2 1

Bug: GHC hangs rather than reporting an occurs check error
by Bryan Donlan 20 Mar '08

20 Mar '08

Hi all, I've found a case where GHC will hang (consuming more and more memory) when it should report an occurs check error. The test case is at http://fushizen.net/~bd/kaos-ghc.loop.tgz - the error in question is that the arguments in the StateT instance for HOLift are reversed like so: diff --git a/src/Kaos/KaosM.hs b/src/Kaos/KaosM.hs index ec4e69a..268250a 100644 --- a/src/Kaos/KaosM.hs +++ b/src/Kaos/KaosM.hs @@ -88,7 +88,7 @@ genlift' unbox box f m = box $ \s -> f (unbox m s) class HOLift m b | m -> b where genlift :: (forall r'. b r' -> b r') -> (forall r. m r -> m r) -instance HOLift m (StateT s m) where +instance HOLift (StateT s m) m where genlift = genlift' runStateT StateT instance (HOLift m b, KaosDiagM r b) => KaosDiagM r m where Thanks, Bryan Donlan

2 4

Optimization beyond the Module Border
by Bernd Brassel 20 Mar '08

20 Mar '08

Hi all, I have noticed that there is a great difference between optimizing modules separately and all at once, e.g., with -fforce-recomp. I have had examples factors up to 15 in run time (and even different behavior in context with unsafePerformIO). Is there any option that makes ghc write out that intermediate optimization data he seems to use in order to get the same efficiency in a module-wise compilation? Greetings Bernd

5 9

Re: [GHC] #2163: GHC makes thunks for Integers we are strict in
by Ian Lynagh 19 Mar '08

19 Mar '08

On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote: > > > W.f = > > \ (x_a5h :: GHC.Num.Integer) -> > > let { > > x'_sa7 [ALWAYS Just S] :: GHC.Num.Integer > > [Str: DmdType] > > x'_sa7 = GHC.Num.plusInteger x_a5h W.lvl } in > > GHC.Num.timesInteger x'_sa7 x'_sa7 > > `let` can be strict in Core - it doesn't always indicate a thunk. Aha! I knew that let was strict for types like Int#, but didn't realise that it could be for "normal" types too. What is it in the above let that shows that it will be evaluated strictly? The "Just S"? Also, what is the advantage to having strictly evaluated let's, both for unboxed and normal types? Presumably it helps with some optimisation - perhaps let-bound things might be inlined, whereas case'd things aren't, which reduces the number of cases the optimiser needs to consider, or something? > (don't worry, this often catches me out too. Perhaps a strict let > should be indicated more explicitly in `-ddump-simpl`). I'd certainly find it useful if it was clearer. Thanks Ian

2 2