April 2007 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ghci and ghc -threaded broken with pipes & forking
by John Goerzen 29 Dec '08

29 Dec '08

Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John

13 44

ghc6.6 on ps3 - compile error in StgCRun
by Tristan Allwood 24 Jun '07

24 Jun '07

Hi, I'm trying to build ghc-6.6 on a sony ps3, but have hit a problem: ------------------------------------------------------------------------ == make all -r; in /home/tora/ghc/ghc-6.6/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP -optc-fno-strict-aliasing -H16m -O -optc-O2 -optc-DNOSMP -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o /tmp/ghc12557_0/ghc12557_0.s: Assembler messages: /tmp/ghc12557_0/ghc12557_0.s:12:0: Error: junk at end of line, first unrecognized character is `@' /tmp/ghc12557_0/ghc12557_0.s:16:0: Error: junk at end of line, first unrecognized character is `@' make[1]: *** [StgCRun.o] Error 1 make: *** [stage1] Error 1 The ps3 is running YDL, and to bootstrap the ghc build I managed to install a powerpc ghc6.6 on the system (downloaded a deb from http://packages.debian.org/cgi-bin/download.pl?arch=powerpc&file=pool%2Fmai… then alien'ed it to get an rpm which seems to work - though ghci is non-functioning) The sources I'm trying to build are the standard ghc http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src.tar.bz2 (and extralibs) >uname -a Linux ebony 2.6.16-20061110.ydl.2ps3 #1 SMP Tue Dec 5 12:35:42 EST 2006 ppc64 ppc64 ppc64 GNU/Linux Any tips / pointers / advice greatfully recieved; TIA, Tristan Allwood

3 5

ghc configure
by C.M.Brown 23 Jun '07

23 Jun '07

Hi, I've noticed that when you run ./configure on a ghc build lot's of repetition occurs. A lot of the time the same checks are being performed for each configure file in the ghc hierarchy. Could it be possible if some of these checks could be done once at a high level and then subsequent configures could refer to these checks to speed up configuration time? It's just configuring ghc on a mac G4 is a very time consuming process in it's own right! Thanks, Kind regards, Chris.

4 5

Wanted: warning option for usages of unary minus
by Isaac Dupree 22 May '07

22 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since the unary negation operator `-' is often considered a wart in Haskell's syntax and in many cases saying "negate" is arguably clearer anyway, I propose adding options to GHC to warn about its use. The only case I don't normally want to be warned about is "negative numeric literals", e.g. (-1), even if in current Haskell they do mean (negate (fromInteger 1)) not (fromInteger (negate 1)) (or equivalently, (fromInteger (negate (fromInteger 1))) as the inner fromInteger === id). I know this would be useful to someone since I caught myself manually cleaning some of my code in this way without the help of warning messages :) Proposed flag names and descriptions (could use a little tidying up) : - -fwarn-unary-minus Causes a warning to be emitted for all usages of the unary operator `-', except those in which its argument is a numeric literal that is not separated from the minus sign by any space (space includes comments). - -fwarn-all-unary-minus For those who hate it with a passion, this option warns about ALL uses of the unary `-' operator, even code like `(-1)'. Opinions? (Should I put a feature request in Trac? Is that what I perhaps should have done in the first place?) Is this simple enough to try to implement myself so I can start getting to know GHC's internals? (I suspect that detecting the adjacency of the "-" to a numeric literal without changing the actual precedence may be a little tricky... -2^6 parses as negate(2^6) and should get a warning, as should (- 2), IMO) Oh, the actual warning message... file:line:column: Warning: Unary minus in expression foo (or, on the next line, In the expression: foo ?) for an appropriate "foo", which has parentheses added to describe the effects of operator precedence, as usual for GHC diagnostic messages (it's just particularly important for making this one easy to understand in some cases) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGBpSHgcxvIWYTTURAt5sAKCEIohHMiuUy9AofhWKzvDOf4rwmgCeJcbj e2RmW+UX2E6omuLpFfIH9fs= =1SnR -----END PGP SIGNATURE-----

5 18

{-# INLINE me_harder #-}
by Duncan Coutts 13 May '07

13 May '07

So I'm trying to program the GHC term rewriting system again (ie the mighty simplifier) and it's not doing what I want it to do without me using unnecessarily large hammers. The crux is that I have a simple function that I want to be inlined early so that my other rules can match on the thing it expands into, however despite the {-# INLINE #-} pragma, it doesn't get inlined until a much later phase when it's too late for the rule to match. So currently I'm forced to use {-# RULES #-} to achieve the same effect, ie expanding the definition in an early phase. This feel like a hack of course. So either the INLINE heuristics could be tweaked to make these cases work or perhaps we should consider adding some other pragma for when we don't want to go by heuristics but are instead deliberately trying to do term rewriting. Anyway, here's the example. It's binary deserialisation. We have a couple important primitives: read :: Int -> (Ptr Word8 -> IO a) -> Get a and the applicative combinators (<$>) (<*>) for Get: fmapGet :: (a -> b) -> Get a -> Get b apGet :: Get (a -> b) -> Get a -> Get b So that we'll be able to match on these, we delay their inlining: {-# INLINE [0] apGet #-} {-# INLINE [0] fmapGet #-} {-# INLINE [0] read #-} The important rules linking these are: {-# RULES "fmap/read" forall f n a. f `fmapGet` read n a = ... "read/read" forall n m f x. read n f `apGet` read m x = ... #-} and finally we have: word8 :: Get Word8 word8 = read 1 peek {-# INLINE word8 #-} So when we write something like: foo :: Get (Word8,Word8,Word8) foo = (,,) <$> Get.word8 <*> Get.word8 <*> Get.word8 we want to expand word8 into it's definition in terms of read and then have the rules fire (which shares the bounds checks). Looking at the simplifier iterations we get to this step: ==================== Simplifier phase 2, iteration 1 out of 4 ==================== PutTest.foo :: Get.Get (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8) [Exported] [] PutTest.foo = Get.apGet @ GHC.Word.Word8 @ (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8) (Get.apGet @ GHC.Word.Word8 @ (GHC.Word.Word8 -> (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8)) (Get.fmapGet @ GHC.Word.Word8 @ (GHC.Word.Word8 -> GHC.Word.Word8 -> (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8)) (Data.Tuple.(,,) @ GHC.Word.Word8 @ GHC.Word.Word8 @ GHC.Word.Word8) Get.word8) Get.word8) Get.word8 Here is where we really must inline word8 or we're going to miss our opportunity once apGet and fmapGet get inlined. Sadly it doesn't inline it here (in phase 2), or in the next phase (in fact it does nothing in phase 1 at all). We get all the way to phase 0 and then go and inline everything (including word8). The behaviour is the same for 6.6 and 6.7.recentish (one month old). If we hit word8 with a bigger hammer: {-# RULES "inline word8" word8 = read 1 peekWord8 #-} then the whole thing works perfectly and we get really nice STG code at the end. I was under the impression that GHC considered a function more 'interesting' if it was mentioned in the LHS of a rule as is the case here. What is the right thing for me to do in this case? Just use the rule to do the inlining? The full source is here: http://haskell.org/~duncan/binary/ Get.hs and GetTest.hs (In the same dir is an example showing the opposite problem, GHC inlining a function when I asked explicitly for it not to. I reported that problem previously. Though I now realise I never filed a bug in trac for that one. I'll file bugs for both.) On the good news side, I'm getting excellent performance results for the serialisation and judging from the STG code for the deserialisation I expect it'll be great too. Duncan

4 7

non-owner-writable files generated in ghc build process?
by Isaac Dupree 12 May '07

12 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When I was doing `rm -r` on a build tree it pointed out that driver/split/ghc-split.prl and driver/mangler/ghc-asm.prl were write-protected. Tacking this down, they're generated from .lprl with unlit... then (in mk/suffix.mk) they are `chmod 444`-ed. Is this a problem? Is the purpose to remind people that those are generated files, so don't change them? (hmm... if someone has a restrictive umask like 027, will this circumvent it? would `chmod -w` make more sense?) I know, I can use `rm -rf` in order to unquestioningly follow UNIX permissions model... Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGNJmgHgcxvIWYTTURAs5IAKCw5ND5vKLimSkIaclz5onqnNHVyACeKCPq bBtTcqD+/qoG3gnDcAtLHc0= =PUgp -----END PGP SIGNATURE-----

3 3

More speed please!
by Duncan Coutts 11 May '07

11 May '07

All, So here's the Put monad for the binary serialisation stuff: newtype Put a = Put { runPut :: (a -> Buffer -> [B.ByteString]) -> Buffer -> [B.ByteString] } data Buffer = Buffer {-# UNPACK #-} !(ForeignPtr Word8) {-# UNPACK #-} !Int -- offset {-# UNPACK #-} !Int -- used bytes {-# UNPACK #-} !Int -- length left This is all good, and pretty quick. Code like the following gets turned into great low level code: foo :: Word8 -> Put () foo !n = do word8 n word8 (n+1) word8 (n+17) It does a straight line sequence of writes into memory (there are rules that combine the bounds checking of adjacent writes). After that it calls the continuation with a new buffer. While almost everything is unboxed, the parameters to the continuation are not unboxed. So we have to allocate a new Buffer structure and pass that to the continuation: let { sat_s1F8 = NO_CCS PutMonad.Buffer! [ww1_s1Es ww2_s1Et ww3_s1Ew sat_s1F4 sat_s1F6]; } in w_s1DY GHC.Base.() sat_s1F8; w_s1DY being the continuation here. However we know that really the parameters to this continuation could really be unboxed since we construct all these continuations explicitly in this module. We could re-write the monad type by manually explicitly unboxing the Buffer argument: newtype Put a = Put { runPut :: (a -> Addr# -> ForeignPtrContents -> Int# -> Int# -> Int# -> [B.ByteString]) -> Addr# -> ForeignPtrContents -> Int# -> Int# -> Int# -> [B.ByteString] } Then we'd get no allocations and no heap checks in the fast path. Note that we could still get a continuation in from the 'outside' with the original type and convert it to one with the above type, though obviously that involves unpacking the arguments. This unpacking is basically what the wrapper of a worker/wrapper pair does of course. Obviously this is ugly. We'd much rather write the original and with just a couple annotations get the above representation. This is what I would like to write: newtype Put a = Put { runPut :: (a -> {-# UNPACK #-} !Buffer -> [B.ByteString]) -> {-# UNPACK #-} !Buffer -> [B.ByteString] } So I'm declaring a type and a data constructor that contains a function that is strict in one of it's arguments. I do not wish to distinguish the strictness in the type however, that is it should be perfectly ok to do this: foo :: Foo -> Buffer -> [B.ByteString] Put foo newBuffer :: Put Foo Suppose that in this case we do not know locally that foo is strict and can take it's args unboxed then upon applying the Put constructor we just have to apply a wrapper function that boxes up the args and supplies them to the wrapped function. Obviously that'd be a pessimisation, having to re-box args, however we can expect programmers to only use that UNPACK pragma when they know that it is going to be a win overall. So the ! on the arg is a semantic change and the pragma is a representation change but not a semantic change. The ! means the obvious thing, that the function is strict in that arg. So either the caller or calle must ensure the arg is evaluated to WHNF. Hmm, is the UNPACK actually needed then? Normally when ghc determines that a func is strict in an arg it make the worker unbox that arg if possible and that always seems to be a win. Mine you, in that case we know what the function is going to do with each arg, where as here we do not so perhaps a separate UNPACK makes sense. This issues crops up quite a bit with Monads I think. For example GHC defines it's IO monad to return an unboxed tuple: newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #)) This is fine for low level internal code, but for everyday monads it'd be nice to be able to write nice code and still get great performance. This applies to monads particularly since they very often fully encapsulate the function used as the internal representation, that is all the sites where the representation function is constructed and taken apart are in a single module. So we can 'see' that all uses are strict in some arg. Or if they're not we might want them to be. So instead of doing an analysis to figure out if we're always using it strictly (which is something that jhc/grin might be able to do?) we can just declare the data representation to be strict like we do with ordinary algebraic data types, that way it propagates strictness to the usage sites which is much more convenient than going around strictifying all the usage sites in an attempt to make an analysis notice that it's safe to do a representation change. Ok, I'm done. :-) Duncan

5 10

ghci dynamic linking
by Frederik Eaton 10 May '07

10 May '07

Hello, I am wondering how to link a package with some dynamic libraries in a way that works with ghci. If I run the command LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 ghci -package mypackage then it is successful; I am able to use package mypackage in ghci. But if I omit the LD_PRELOAD=... part then ghci complains about missing symbols. How do I configure my package so that the LD_PRELOAD=... part of the command is not necessary? Thanks, Frederik

3 3

recent Windows installer for ghc head?
by Conal Elliott 04 May '07

04 May '07

I'd like to try out the new & improved combination of type classes and GADTs, which I understand is only in head. Is there a recent working windows installer for head? Thanks, - Conal

4 5