Glasgow-haskell-users

Download

glasgow-haskell-users@haskell.org

October 2006

69 participants
82 discussions

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