- Glasgow-haskell-users

Problem with lexically scoped type variables.
by Mirko Rahn 03 Oct '06

03 Oct '06

Dear all, in http://www.haskell.org/pipermail/glasgow-haskell-users/2006-January/009565.… Simon Peyton-Jones asks for programs that are broken by the proposed change. Here is a nearly real world one: {-# OPTIONS_GHC -fglasgow-exts #-} import Control.Monad import Control.Monad.ST import Data.Array.MArray import Data.Array.ST import Data.STRef import Data.Set hiding (map,filter) -- a store that allows to mark keys class Mark m store key | store -> key m where new :: (key,key) -> m store mark :: store -> key -> m () markQ :: store -> key -> m Bool seen :: store -> m [ key ] -- implementation 1 instance Ord key => Mark (ST s) (STRef s (Set key)) key where new _ = newSTRef empty mark s k = modifySTRef s (insert k) markQ s k = liftM (member k) (readSTRef s) seen s = liftM elems (readSTRef s) -- implementation 2 instance Ix key => Mark (ST s) (STUArray s key Bool) key where new bnd = newArray bnd False mark s k = writeArray s k True markQ = readArray seen s = liftM (map fst . filter snd) (getAssocs s) -- traversing the hull suc^*(start) with loop detection trav suc start i = new i >>= \ c -> mapM_ (compo c) start >> return c where compo c x = markQ c x >>= flip unless (visit c x) visit c x = mark c x >> mapM_ (compo c) (suc x) -- sample graph f 1 = 1 : [] f n = n : f (if even n then div n 2 else 3*n+1) t1 = runST (trav f [1..10] (1,52) >>= \ (s::STRef s (Set Int)) -> seen s) t2 = runST (trav f [1..10] (1,52) >>= \ (s::STUArray s Int Bool) -> seen s) In ghc-6.4.2 this works as expected, but ghc-6.5.20061001 says B.hs:40:44: A pattern type signature cannot bind scoped type variables `s' unless the pattern has a rigid type context In the pattern: s :: STRef s (Set Int) In a lambda abstraction: \ (s :: STRef s (Set Int)) -> seen s In the second argument of `(>>=)', namely `\ (s :: STRef s (Set Int)) -> seen s' Unfortunately I cannot find an easy workaround but use similiar patterns somewhere deeply nested in my programs... Is there a simple workaround? Could we relax the rules for lexically scoped type variables a bit? Regards, Mirko Rahn -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

3 6

GHC on MacOS
by Aaron Tomb 03 Oct '06

03 Oct '06

Hello, I have an Intel Mac laptop which isn't reliably accessible remotely, but which I'm happy to use to test and (hopefully) help fix GHC builds. I'm not positive that I'll have tons of available time, but I suspect I'll have enough to do at least some good. Right now, I have the ghc-6.6 branch (as of 2006-10-01) built and running happily. Given a recent binary to bootstrap with, the standard configure/make/make install process just works. Everything I've tried to compile with it has worked, but there are a number of areas that I'm sure I haven't touched. I went to the GHC Hackathon, so I have some idea of how GHC works internally at this point, and I'd love a chance to poke around and try to fix things as they come up. Since I haven't come across any problems so far, does anyone else have experience they would like to share? Someone mentioned STM, but didn't say much. There are only three tickets in Trac that seem specific to OS X, though I may be missing something. I'll run the test suite tonight and see how it fares. Aaron

1 0

Map.genericSize
by Serge D. Mechveliani 02 Oct '06

02 Oct '06

Dear GHC developers, Can you, please, provide Map.genericSize :: Map -> Integer in addition to Map.size :: Map -> Int ? For I use `Map.size', a bit, and need its variant which is both O(1) and Integer (because Int is less reliable). Probably, this is not hard to arrange. The same request is for Data.Set. What do you think of this? ----------------- Serge Mechveliani mechvel(a)botik.ru

5 4

Re: FW: [GHC] #916: windows installer should play nice with otherHaskell tools
by Claus Reinke 02 Oct '06

02 Oct '06

Simon, Sigbjorn, we have updated the wiki page http://haskell.org/haskellwiki/Installers and would welcome your feedback. (only cc-ed to ghc-users for now, as ghc's is the next installer to be expected; once ghc is on board, we can ask others) Initially, we were tempted to try and specify some ideal installation world, but that turned out to be complicated and unlikely to be something all Haskellers could agree on. So we chose to tackle the issue from the other side instead, trying to pin down the issues on which different installers must not get in each other's way. An oversimplified micro-summary is "hands off, unless the user wants it" - installers should agree on a common file type, lest they disable each other inadvertedly, and they should permit users to bypass file name extension association, file type action registration (right-click menu), and setting of the default action (double-click). That should hopefully enable initial conformance with minimal changes, as the next release is imminent (though I'm led to believe that nothing is straightforward about creating Windows installers;-). Once the various installers no longer get in each other's way, things can grow from there, later. Over to you, Claus and Neil ----- Original Message ----- From: "Simon Peyton-Jones" <simonpj(a)microsoft.com> To: "Claus Reinke" <claus.reinke(a)talk21.com>; "Neil Mitchell" <ndmitchell(a)gmail.com> Cc: "Sigbjorn Finne" <sof(a)galois.com> Sent: Friday, September 29, 2006 11:38 AM Subject: RE: FW: [GHC] #916: windows installer should play nice with otherHaskell tools Claus, Neil This is all v helpful. Can you let Sigbjorn (and me) know when you have converged to a common mind, so that he can think about how to implement it? No point in doing work until there is an agreed spec! Thanks Simon

2 1

more fixups for GHC docs
by Bulat Ziganshin 01 Oct '06

01 Oct '06

Hello glasgow-haskell-users, 1. section 7.11.6 contains small typo - both %note are "%note foo" while CORE pragmas use "foo" and "bar" 2. section 7.13 notes that generic classes was broken in GHC 5.02. afaik, they worked at least in GHC 6.4 also it will be great if each paragraph of Release Notes will link to corresponding section in documentation for further reading. now we don't have links for impredicative polymorphism, bang patterns, GC improvements (we can point to http://hackage.haskell.org/trac/ghc/ticket/650) -I RTS flag, -split-objs flag (and also it will be great to mention here that its using allows to reduce size of binaries) i think that it should be mentioned here that parallel arrays support is omitted in 6.6 despite this support was never documented one more small suggestion - in GHC 6.4.3 add "-A5m" RTS flag to compiler itself in order to make it faster and last question - i don't like inclusion of unix and win32 in a list of core libs. why they are here? may be it's possible to include small modules with functionality required for compiler itself in GHC.* hierarchy and then move the rest into extra libraries? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 11

Re[2]: [GHC] #710: library reorganisation
by Bulat Ziganshin 01 Oct '06

01 Oct '06

Hello GHC, Wednesday, September 27, 2006, 9:32:37 PM, you wrote: > I also managed to fork off > * `array` > * `containers` (`Data.{FunctorM, Foldable, Graph, IntMap, IntSet, Map, > Set, Queue, Sequence, Tree, Traversable`) > * `bytestring` > * `printf` > and it also looked plausible that `io` and/or `concurrency` would also be > able to be pulled out, but by that point I had run into enough of the > issues above that I stopped working on it. The rest can be looked at in > more detail when we come to do this for real. i will start answering from this easy part. First, ByteString - it was just integrated and it should be still easy enough to deintegrate this again. but after that, ByteString package should be included in list of extra packages array - look at my ArrayRef lib: http://haskell.org/haskellwiki/Library/ArrayRef http://www.haskell.org/library/ArrayRef.tar.gz except for a few still unfinished features, it's almost completely backward compatible with ghc 6.6 arrays implementation. so, i propose to use it, although some code may require to move between base and arrayref libs. say, unboxed references or GHC.* modules may be better looking in base lib while Ix class (which, i think, is compiler-independent) should be moved out of base. Also, HashTable and may be some other code is Array-dependent (although, on the other side, it may be easily rewritten to use only array primitives described in GHC.ArrBZ) containers, i.e. almost whole Data.* hierarchy - definitely yes other packages may be also based on existing hierarchies - Foreign.*, System.* GHC Handle I/O, i.e. GHC.Hanle, GHC.IO and part of GHC.IOBase - should be moved to separate package at some time. just because this I/O package are rather cumbersome and i hope that it will be replaced by Streams-like package concurrency - definitely. nothing depends on it, and it's separate concept that may be even not implemented in other compilers. but we should first decide where to place primitive operations (i.e. GHC.Conc) - leave them in base package or bundle into the same package as high-level operations? i prefer the first variant. btw, STM package is already playing by these rules Text.* - it would be great to move this into separate package, allowing to make alternative Read/Show implementations but it seems impossible because GHC deriving mechanism use these concrete implementation printf - i think it's too small to make any separate package -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

FW: [GHC] #916: windows installer should play nice with other Haskell tools
by Simon Peyton-Jones 28 Sep '06

28 Sep '06

Claus, Neil Thanks for raising this. I talked to Sigbjorn about it at ICFP. If you two can form a consensus (giving others an opportunity to speak up) about what should be the desirable behaviour for GHC's installer, he's happy to implement it. (Caveat: unless something turns out to be a lot of work, but that's unlikely.) You mention two specifics: - make file type registration optional - do not overwrite existing default handler for .hs/.lhs, just add new non-default handlers I believe that the former is done already; not sure about the latter (Sigbjorn will correct me if I'm wrong). I don’t know what a non-default handler is. Is there anything else? There was mention of better icons. What did you have in mind by "coordinate with Neil for WinHugs, and possibly with others"? Of course we'd like to coordinate... but about what specifically (apart from the above two)? Thanks Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of GHC Sent: 28 September 2006 14:46 To: glasgow-haskell-bugs(a)haskell.org Subject: [GHC] #916: windows installer should play nice with other Haskell tools #916: windows installer should play nice with other Haskell tools ----------------------------------------+----------------------------------- Reporter: claus.reinke(a)talk21.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.4.2 Severity: normal | Keywords: Os: Windows | Difficulty: Unknown Architecture: Unknown | ----------------------------------------+----------------------------------- traditionally, the windows installers have registered ghci as the default tool to operate on .hs/.lhs files, without regard for existing file type associations. that has been a real pain for those of us who like to use many tools on haskell files. could you please ensure that future installers are more cooperative? - coordinate with Neil for WinHugs, and possibly with others - make file type registration optional - do not overwrite existing default handler for .hs/.lhs, just add new non-default handlers (so people can use their own defaults, eg. editors, and still have easy access to ghci, hugs, ..) this has come up many times. see also: http://www.haskell.org/pipermail/glasgow-haskell-users/2004- March/006402.html http://www.haskell.org/pipermail/hugs-users/2006-February/000656.html http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/14819/ http://www.haskell.org/pipermail/glasgow-haskell-users/2006- September/011107.html http://www.haskell.org/pipermail/glasgow-haskell-users/2006- September/011110.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

4 7

Using close to 3GB heap on Linux, 32 bit
by Alex Iliev 28 Sep '06

28 Sep '06

Hello, I'm trying to run a program on rather large data (mostly an Inductive.Graph), and finding it will not grow beyond 2GB RAM, as reported by top. An allocation attempted by the runtime failed, with: out of memory (requested 1048576 bytes) This is unfortunate, as the machine has 4GB, and on stock Linux (+/- 2.6.9) a process can allocate close to 3GB (which is achievable with malloc as long as the chunks allocated are about 16MB or smaller). Any suggestions for allowing the program to grow bigger? I've tried various RTS settings, like -M2800M, -A10m, -H2000M (it seems to ignore -H with more than 2000M), but as soon as the program tries to grow beyond 2GB, it errors out. I'm using 6.4.1 (Debian testing) Thanks! alex

1 0

release notes
by Bulat Ziganshin 28 Sep '06

28 Sep '06

Hello Simon, i write to you, Simon (not to Igloo), because these changes require a knowledge of new GHC language features that you have implemented second paragraph of release notes (http://www.haskell.org/ghc/dist/current/docs/users_guide/release-6-6.html) is still erroneous. it mention two _different_ things - addition of impredicative polymorphism and changes in scoped type variables. Your mail mentioned here is about variables while section 7.4.9 is about polymorphism. There is also section 7.4.10 what say about variables and in my POV is much more readable than your letter. so i propose to write smth like the: - GHC now handles impredicative polymorphism, see Section 7.4.9, ⌠Impredicative polymorphism■ for the documentation - There are changes to the way scoped type variables work, see Section 7.4.10 for details. Shortly saying, the following is no more works: f (x::a) = sizeOf (undefined::a) g :: a = genericLength [] `asTypeOf` (undefined::a) while Section 7.4.10 should mention "Simon's letter" as containing more technical details. i also propose to add here explanations of how old code can be converted to new syntax. it may be obvious for you but not for us, common haskellers :D f (x::a) = sizeOf (undefined::a) should be now written as f :: a -> Int f (x::a) = sizeOf (undefined::a) to reach compatibility with old GHC versions and Hugs. well, i'm not language lawyer and not sure what is the best way, but at least using 'forall' to bring 'a' into scope is not H98-compatible It's very important to mention that this change means _dropping_ capabilities, not adding new ones, because it is completely unobvious from current docs. i don't realized it until i've compiled my program and spend several hours trying to understand 7.4.10, your letter and then 7.4.10 again :) i hope that proposed changes will greatly simplify this "learning curve" :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Year 2038 problem in GHC 6.4.2 runtime
by Cyril Schmidt 27 Sep '06

27 Sep '06

As far as I can see, the current (6.4.2) GHC runtime suffers the year 2038 problem; that is, the System.Time module does not support dates from 2038 onwards (the code below reproduces the problem). Is this bug scheduled to be fixed in the near future (my search in Trac yielded nothing) ? Regards, Cyril ___ The following code reproduces the problem with the Windows distribution of GHC 6.4.2: module Main where import System.Time main = putStrLn $ show $ toClockTime $ CalendarTime 2038 January 31 12 0 0 0 Sunday 0 "GMT" 0 False

3 5