July 2007 - Glasgow-haskell-users

haskell's prefix exprs
by Christian Maeder 10 Jul '07

10 Jul '07

Hi, I would like haskell to accept the following (currently illegal) expressions as syntactically valid prefix applications: f = id \ _ -> [] g = id let x = [] in x h = id case [] of [] -> [] i = id do [] j = id if True then [] else [] The rational is that expressions starting with a keyword should extend as far as possible (to the right and over several lines within their layout). In this case the above right hand sides (rhs) are unique juxtapositions of two expressions. (This extension should of course apply to more than two expressions, i. e. "f a do []") Furthermore the above rhs are all valid if written as infix expressions: f = id $ \ _ -> [] g = id $ let x = [] in x h = id $ case [] of [] -> [] i = id $ do [] j = id $ if True then [] else [] (In fact, maybe for haskell' "$" could be changed to a keyword.) Does this pose any problems that I haven't considered? I think only more (and shorter) illegal haskell programs will become legal. Cheers Christian Maybe someone else can work out the details for Haskell's grammar

2 2

rpm for RHEL4
by chuckanut 06 Jul '07

06 Jul '07

Hi, I am looking for an rpm for Red Hat enterprise linux 4 for x86_64. Can anyone point me to such an rpm? I don't think the FC5 binary will work on EL4. Thanks

1 0

Re[2]: [GHC] #1338: base package breakup
by Bulat Ziganshin 06 Jul '07

06 Jul '07

Hello GHC, Friday, July 6, 2007, 10:04:05 PM, you wrote: > #1338: base package breakup > Not clear what to do with these: > Control.Applicative > Data.Foldable, Data.Traversable > Data.Map, Data.IntMap, Data.Set, Data.IntSet > Data.Sequence, Data.Tree > Data.HashTable > Data.Graph > ---> new package collections? containers? or split further? > (dep. on array, generics, concurrent) package named Collections already exists. one possible way of splitting these modules would be separation of Control.Applicative, Data.Foldable, Data.Traversable while changing names of established modules and adding new hierarchy roots aren't good ideas, may be it will better to rename them to Class.* or even Concept.*? Monads, Data/Typeable, i/o Streams and other classes may be moved to the same place. the intention is to split packages to those defining concepts (classes) and whose implementing them, with multiple packages that implements these concepts > Data.Array.* > --> new package array (maybe; I'm slightly dubious here) > (dep. on concurrent for Data.Array.Diff) definitely! > Needs the above to happen first: > Data.Generics.* > --> generics (maybe; Data class is defined for everything and is > derivable) how about using standalone deriving in this package? derive Data for Int, Handle.... > Needs Data.Array.Diff to move out of base first: > Control.Concurrent.*, System.Timeout > --> new package concurrent how about renaming System.Timeout to Control.Concurrent.Timeout ? > Needs concurrent to be done first: > Data.Unique > --> new package unique (dep on concurrent) may be it's better to consider it as one more multi-threading service and move it into concurrent package? separate package for 60 lines-long module doesn't seem like a good approach > Will happen soon: > Data.ByteString.* > --> bytestring (dep. on base, generics, array) > Other modules we might move: > Text.Printf, Data.Monoid, System.CPUTime afaiu, Data.Monoid should go together with Foldable and so on? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: problem compiling an older Haskell program with GHC 6.6.1
by Peter Tanski 06 Jul '07

06 Jul '07

On Fri, 6 Jul 2007 09:59:41 -0400 Scott Stoller wrote: > I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, > with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). > <snip> > > Set.hs:26:7: > Could not find module `Data.FiniteMap': > locations searched: > Data/FiniteMap.hs > Data/FiniteMap.lhs > *** Deleting temp files: > Deleting: /tmp/ghc13306_0/ghc13306_0.dep > *** Deleting temp dirs: > Deleting: /tmp/ghc13306_0 > make: *** [depend.mak] Error 1 > > is this a backwards-compatibility issue between GHC 6.6.1 and older > versions of GHC? is there a simple workaround? The problem is that the Data.FiniteMap library has been deprecated and renamed to Data.Map. See http://www.haskell.org/ghc/dist/current/ docs/libraries/base/Data-Map.html . The solution is to go through paradox and change references to Data.FiniteMap to Data.Map and, especially, to check that functions from Data.FiniteMap now have the form of Data.Map. Changing the functions should not be too hard: mostly swapping variables around. You may also run into namespace collision problems with Data.List (GHC will alert you), in which case: import Data.Map as Map import Data.List as List and for each function that collided, such as map or fold, specify which one you are using: Data.map ... List.map ... Otherwise you should be fine. The change from Data.FiniteMap to Data.Map has been around for a little while now but there are still quite a few old libraries kicking around that use FiniteMap and need to be updated. Cheers, Pete

1 0

Prefix form of unboxed tuple
by Neil Mitchell 06 Jul '07

06 Jul '07

Hi, The following works fine: ghci -fglasgow-exts Prelude> case (# 1 , 2 #) of (# a , b #) -> error $ show (a,b) *** Exception: (1,2) You might expect there to be a prefix form of the unboxed tuple: Prelude> case (#,#) 1 2 of (# a , b #) -> error $ show (a,b) <interactive>:1:7: parse error on input `,' But there isn't. I've added special code into the Yhc code generator to deal with this particular constructor, so it no longer effects me. Thanks Neil

5 6

problem compiling an older Haskell program with GHC 6.6.1
by Scott Stoller 06 Jul '07

06 Jul '07

hi, I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). in case anyone else wants to try it, I put the paradox source code at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz in the Makefile, I deleted "-package lang" from HFLAGS, and added "-v" to it. then I typed "make". I got the following error message: Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1 Using package config file: /usr/local/lib/ghc-6.6.1/package.conf wired-in package base mapped to base-2.1.1 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.1 Hsc static flags: -static Created temporary directory: /tmp/ghc13306_0 *** Chasing dependencies: Set.hs:26:7: Could not find module `Data.FiniteMap': locations searched: Data/FiniteMap.hs Data/FiniteMap.lhs *** Deleting temp files: Deleting: /tmp/ghc13306_0/ghc13306_0.dep *** Deleting temp dirs: Deleting: /tmp/ghc13306_0 make: *** [depend.mak] Error 1 is this a backwards-compatibility issue between GHC 6.6.1 and older versions of GHC? is there a simple workaround? I can't easily use an older version of GHC, because I don't see binary distributions of older versions of GHC for Solaris x86. any advice would be greatly appreciated. best regards, scott

3 2

RTS/Garbage Collector idea
by Isaac Dupree 06 Jul '07

06 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's often bothered me that there is unneeded duplication in the heap, if you do something the compiler doesn't manage to optimize like f [a,b,c,d] = Foo bar [a,b,c,d] or (reverse . reverse) or using () or Int(eger) or ... or Bool boxes in multiple places in your program that have the same value. A referentially transparent difference in your program could be the difference between constant memory usage and a memory leak (I think -- although this proposal/idea will not "tie the knot" for you or deal well with cyclic data structures at all, in fact). I was thinking, since we have a copying garbage collector that reassigns all pointers anyway, could we detect the "identical" heap objects and for each set of identical ones, have all thunks that pointed to any of them, now point to the single one that is created in the target space? This might not have much effect. (and seems likely to be slow and possibly have a complex interaction with parallel and/or incremental GC...) Maybe it should not be done on _every_ garbage collection. First to implement/try might be just detecting those duplicates so we have some idea how much effect such an "optimization" would even have. (any idea how easy/possible that is (or just what the answer is;)?) Examples: evaluated (543::Int) somewhere ends up pointing to the same (543# :: Int#) in the heap as another (543::Int) somewhere does. 8:8:2:3:[] 9:9:2:3:[] The []s become shared, then the "3:[]"s, then the "2:3:[]"s, ending 8:8:x 9:9:x where x is 2:3:[] 8:8:2:3:(*) 9:9:2:3:(*) where (*) is the *same* object, maybe an unevaluated thunk, maybe some list. After (*)'s creation, two different parts of code decided to construct their own lists with that as their tail. Eventually becomes: 8:8:x 9:9:x where x is 2:3:(*) Two thunks that merely have the same code shouldn't be combined because it could be the [1..] [1..] sharing memory-leak to the extreme! It would seem safe to combine thunks that only produce something small like an Int, but they can actually produce a complex Exception - so, no combining of thunks. (also... must be careful in this area of breaking the IO monad-sequencing(maybe?), but I think it's quite safe as long as only already-evaluated heap objects are combined) I wonder how this interacts with polymorphic (list-nil of different types), or with merely structurally equivalent, data (if they're identical, merging shouldn't ever be a problem! at least as long as no-one relies on something like "if (unsafe pointer equality) then (same static type)"...) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdmJaHgcxvIWYTTURAjAhAJ9WHwzxuJPuqouol05K7+QHkT3IigCglOpw VtHCSxcy8E+w7OtCafU8pFM= =BqAi -----END PGP SIGNATURE-----

6 6

Need help understanding the Coverage Condition
by Philip K.F. Hölzenspies 04 Jul '07

04 Jul '07

L.S., I have difficulty understanding the Coverage Condition. Hopefully, someone has the time and is willing to explain this to me. Obviously, I went ahead and hacked together something horribly entangled, but I found a small example that already shows the behaviour I do not understand. Type-level addition of Church numerals: {- begin -} {-# OPTIONS -fglasgow-exts #-} data Z -- Zero data S x -- Successor of x class Add a b c | a b -> c instance Add Z q q instance Add p q r => (S p) q (S r) {- end -} The error GHCi produces is: Illegal instance declaration for `Add (S x) y (S z)' (the Coverage Condition fails for one of the functional dependencies; Use -fallow-undecidable-instances to permit this) In the instance declaration for `Add (S x) y (S z)' Failed, modules loaded: none. I checked the user guide (7.4.4.1) for criteria for functional dependencies and checked that I do not violate the assertions. I don't violate assertions 1a and 1b, but assertion 2 (the coverage condition) I have trouble reading: The coverage condition. For each functional dependency, tvc_left -> tvs_right, of the class, every type variable in S(tvs_right) must appear in S(tvs_left), where S is the substitution mapping each type variable in the class declaration to the corresponding type in the instance declaration. In my mind, in this case: tvs_left = {a,b} tvs_right = {c} S(tvs_left) = {p,q} S(tvs_right) = {r} What "occur in" means (mappings of type variables occurring in mappings of other type variables), I really don't quite understand. The example in the manual under 7.4.4.2, viz: instance Mul a b c => Mul a [b] [c] where x .*. v = map (x.*.) v seams related, but unfortunately is not elaborated upon beyond "[it] does not obey the coverage condition" The suggested flag to "allow undecidable instances" is throwing me off, since it seems very unambiguously decidable to me. Regards, Philip

3 3

Vote for GHC 6.8 bugs!
by Simon Peyton-Jones 03 Jul '07

03 Jul '07

Friends, We are gearing up towards at GHC 6.8 release. You can see details of what will be in it in the GHC status report for April http://hackage.haskell.org/trac/ghc/wiki/Status/April07. One symptom of the sharply-increased use of GHC is the sharply-increased number of bug reports and feature requests. We have no fewer than 200 milestoned for 6.8! You can see a summary here: http://hackage.haskell.org/trac/ghc/roadmap In reality we're unlikely to fix all 200, at least not without a lot of help from our friends. Inevitably, we have to prioritise. One way we do that is by using our (unreliable) perception of which bugs you (GHC's users) care about. This message is to invite you to improve the accuracy of this perception, by voting for the bugs you care about. We have just instituted a cheap-and-cheerful mechanism for voting. Each bug has a 'cc' field. To vote, just add your email address to the cc field! Better still, add a note to say why you care, and/or add a test case. We'll use the number of cc's (and an informal impression of any notes you've added) to guide our priorities. Adding yourself to the cc list means you'll get mail whenever anyone modifies the Trac report, which keeps you informed of what's going on. (You have to log in to edit Trac reports. Currently, new accounts are disabled for boring spammy reasons. That will be fixed when we upgrade Trac, but meanwhile, log in as guest, password guest.) It's not a perfect system, but we think it'll give useful extra guidance. So please go ahead and vote. But better still, help us fix bugs! GHC is open-source software, and it has a very large "surface area" (many platforms, many libraries, many features, documentation, tools, etc etc). Lots of people help make GHC good -- please join in (see the "Joining in" list in the GHC Wiki sidebar http://hackage.haskell.org/trac/ghc/wiki/) thanks Simon

3 2

How to compile .hc files with gcc?
by Srđan Stipić 03 Jul '07

03 Jul '07

I wanted to compile simple Haskell program (simple.hs) to .c and after that to target platform (x86). I did the following things: ghc -C simple.hs mv simple.hc simple.c gcc -c simple.c -I/usr/lib/ghc-6.6/include/ And I got the following error message: In file included from /usr/lib/ghc-6.6/include/Stg.h:148, from treci.c:3: /usr/lib/ghc-6.6/include/Regs.h:220: warning: call-clobbered register used for global register variable /usr/lib/ghc-6.6/include/Regs.h:226: warning: call-clobbered register used for global register variable /tmp/ccBtIPsT.s: Assembler messages: /tmp/ccBtIPsT.s:31: Error: junk at end of line, first unrecognized character is `-' /tmp/ccBtIPsT.s:63: Error: junk at end of line, first unrecognized character is `-' How to compile .hc files with gcc? Tnx, Srdjan

2 2