March 2008 - Glasgow-haskell-users

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

Bug or not-yet-supported?
by Niklas Broberg 17 Mar '08

17 Mar '08

I haven't payed much attention to how much of type families is/should be implemented for 6.8.2. What of equality constraints? The following parses alright, but can't be used it seems. ------------------------------------ module Foo where class C a where proof :: a instance (a ~ Int) => C a where proof = 1 ------------------------------------ %> ghci -fglasgow-exts -XUndecidableInstances Foo.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, modules loaded: Foo. *Foo> proof :: Int : panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-mingw32): nameModule $dC{v aoz} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ------------------------------------ I would follow that last advice if I knew this was *supposed* to work. :-) Cheers, /Niklas

2 2

timer_create
by Christian Maeder 16 Mar '08

16 Mar '08

Hi, my binary distribution http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-linux.t… creates binaries that fail on some i386 linux boxes with: timer_create: Invalid argument I've built the distribution with gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) and the file lib/ghc-6.8.2/include/ghcautoconf.h contains: #define HAVE_TIMER_CREATE 1 The failing machine uses gcc version 3.3.5 and ./configure within the ghc-6.8.2 sources says: checking for a working timer_create(CLOCK_REALTIME)... no Take this as a warning when using my binary-dist above (or when building your own). Or is there a work around (apart from creating a new binary-dist using ghc-6.6.1)? Cheers Christian

4 6