- Glasgow-haskell-users

A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
by Daniel Gorín 28 May '13

28 May '13

Hi all, Given the ongoing discussion in the libraries mailing list on replacing (or removing) list functions in the Prelude in favor of the Foldable / Traversable generalizations, I was wondering if this wouldn't be better handled by a mild (IMO) extension to the module system. In a nutshell, the idea would be 1) to allow a module to export a specialized version of a symbol (e.g., Prelude could export Foldable.foldr but with the specialized type (a -> b -> b) -> b -> [a] -> b) and 2) provide a disambiguation mechanism by which when a module imports several versions of the same symbol (each, perhaps, specialized), a sufficiently general type is assigned to it. The attractive I see in this approach is that (enabling an extension) one could just import and use Foldable and Traversable (and even Category!) without qualifying nor hiding anything; plus no existing code would break and beginners would still get the friendlier error of the monomorphic functions. I also expect it to be relatively easy to implement. In more detail, the proposal is to add two related language extensions, which, for the sake of having a name, I refer to here as MoreSpecificExports and MoreGeneralImports. 1) With MoreSpecificExports the grammar is extended to allow type annotations on symbols in the export list of a module. One could then have, e.g., something like: {-# LANGUAGE MoreSpecificExports #-} module Data.List ( ... Data.Foldable.foldr :: (a -> b -> b) -> b -> [a] -> b , Data.Foldable.foldl :: (b -> a -> b) -> b -> [a] -> b ... ) where import Data.Foldable ... instance Foldable [] where ... For consistency, symbols defined in the module could also be exported specialized. The type-checker needs to check that the type annotation is in fact a valid specialization of the original type, but this is, I think, straightforward. 2) If a module imports Data.List and Data.Foldable as defined above *without* the counterpart MoreGeneralImports extension, then Data.List.foldr and Data.Foldable.foldr are to be treated as unrelated symbols, so foldr would be an ambiguous symbol, just like it is now. If on the other hand a module enables MoreGeneralImports and a symbol f is imported n times with types T1, T2, ... Tn, the proposal is to assign to f the most general type among T1... Tn, if such type exists (or fail otherwise). So if in the example above we enable MoreGeneralImports, foldr will have type Foldable t => (a -> b -> b) -> b -> t a -> b, as desired. (It could be much more interesting to assign to f the least general generalization of T1...Tn, but this seems to require much more work (unless GHC already implements some anti-unification algorithm); also I'm not sure whether this would interact well with GADTs or similar features and in any case this could be added at a later stage without breaking existing programs). Would something like this address the problem? Are there any interactions that make this approach unsound? Any obvious cons I'm not seeing? Feedback is most welcome! Thanks, Daniel

6 11

Re: porting to uClibc-based 686 Linux
by Dubiousjim 21 May '13

21 May '13

Just to follow-up on my earlier emails about trying to port GHC to a uClibc-based Linux, I finally did get this working, on both x86 and x86_64. There were a bunch of small stumbling blocks and one big one that I finally traced to the fact that the native gcc on my target system had the Gentoo hardening patches, and one needed to supply a "-nopie" option to selectively disable these. (This was counter-intuitive because the error messages made it seem that what was wanted was to *enable* PIE compiling, not to disable it.) I finally identified this issue when reading http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml. Anyway, I've written up what it took to port GHC to our system on our distro's wiki: http://wiki.alpinelinux.org/wiki/Porting_GHC_to_Alpine Perhaps that might help others attempting similar feats, or might help the ghc devs working on the build system to make this less painful in the future. -- dubiousjim(a)gmail.com

1 0

nightly builds: empty directory
by Henning Thielemann 20 May '13

20 May '13

The page http://www.haskell.org/ghc/download refers to directories for the nightly builds, that are actually empty: http://www.haskell.org/ghc/dist/current/dist/ http://www.haskell.org/ghc/dist/stable/dist/ :-(

3 2

A type not inferred with RankNTypes
by Akio Takano 13 May '13

13 May '13

Hi, The attached program does not typecheck if I don't include a type signature for 'bar' (the line C). I can't figure out if this is a limitation in the type system or a bug in GHC. One thing that confuses me is that replacing the line (B) with (A) makes the program typecheck. Could anyone help me figuring out what is going on? I'm using GHC 7.6.2. The error was: % ghc forall.hs [1 of 1] Compiling Foo ( forall.hs, forall.o ) forall.hs:18:11: Could not deduce (Fractional a) arising from the literal `0.1' from the context (Num (Scalar t), Scalar t ~ a) bound by a type expected by the context: (Num (Scalar t), Scalar t ~ a) => AD t at forall.hs:18:7-13 Possible fix: add (Fractional a) to the context of a type expected by the context: (Num (Scalar t), Scalar t ~ a) => AD t or the inferred type of bar :: a In the first argument of `foo', namely `0.1' In the expression: foo 0.1 In an equation for `bar': bar = foo 0.1 Regards, Takano Akio

3 2

Missing snapshots
by Mateusz Kowalczyk 13 May '13

13 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, On the GHC download page [1], there are no available snapshots. Both HEAD and STABLE branch dist directories are empty. Any idea what the deal is? [1] - http://www.haskell.org/ghc/download - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRj4bJAAoJEM1mucMq2pqXahAQAKS+IbI7BReGmuNWaPvkova5 eg+4yKcgC3wMeeOBocSYC7B+8x6p0XZaz8gY2BaOOfInDWeuCdHtXAtd3VCQf/5B ZLTPxZztFwW9TNn28YnW9OmB09H3fmsFT3eMRYWJ7sEkVuuetWmsbYHKlUfXCs1o f3fzK9N6iauvCMpbrYQyh1CIObltmh9xIuLl3pAQ5rFOlGqPrW8p3bMxyk1KF0gA 973yBgsWV0rlPx2/xysXXlxhZIpK5LLzJVzCKMBEqCE+8Uii/jtLFyps2ZCYOiI/ q4634JzTj13LR+wlxIRRQUqySTklGvBoWU0n5ZIhlB8AvMxoc7UCn7LfYMYDnwBb C9Y9PMLoPS3XCVqrN2pQ8UCnqaTgzGRYAvbDjQGb51ta+DgppYnz7pKw+fWnV2X+ +OEjyEe10CQ0hsLyQ1mRUi/dI2b0RyypRP/q0PZiQ8qYurwel3W8+nsbt9NvkEdo ZzNKmF+lRJGQEuj4cILkdepHX9DOhjBgIRma6Y6BcaurAnJtDKFrP9a5OAV7g1CB T2tAJiEuYUHtIrAMaRqcRsCXwi/+1jJTv/bmeoAiniXh15l56L8dIQLt1Og05Dsq haZqiLxOKzCib7k9AZJgE0wd8B1mFXv0E31cYCyMworGJU89aWkaKG+Bjlf2xWOS mqVoJArrZCv7tkYoLdN2 =rENI -----END PGP SIGNATURE-----

4 3

Why do remaining HECs busy-wait during unsafe-FFI calls?
by Herbert Valerio Riedel 06 May '13

06 May '13

Hello, Recently, I stumbled over E.Z.Yang's "Safety first: FFI and threading"[1] post and then while experimenting with unsafe-imported FFI functions I've noticed a somewhat surprising behaviour: Consider the following contrived program: --8<---------------cut here---------------start------------->8--- import Foreign.C import Control.Concurrent import Control.Monad import Data.Time.Clock.POSIX (getPOSIXTime) foreign import ccall unsafe "unistd.h sleep" c_sleep_unsafe :: CUInt -> IO CUInt main :: IO () main = do putStrLnTime "main started" _ <- forkIO (sleepLoop 10 >> putStrLnTime "sleepLoop finished") yield putStrLnTime "after forkIO" threadDelay (11*1000*1000) -- 11 seconds putStrLnTime "end of main" where putStrLnTime s = do t <- getPOSIXTime putStrLn $ init (show t) ++ "\t" ++ s sleepLoop n = do n' <- c_sleep_unsafe n unless (n' == 0) $ do putStrLnTime "c_sleep_unsafe got interrupted" sleepLoop n' --8<---------------cut here---------------end--------------->8--- When compiled with GHC-7.6.3/linux/amd64 with "-O2 -threaded" and executed with "+RTS -N4", the following output is emitted: 1367838802.137419 main started 1367838812.137727 after forkIO 1367838812.137783 sleepLoop finished 1367838823.148733 end of main which shows that the forkIO of the unsafe ccall effectively blocks the main thread; Moreover, when looking at the process table, I saw that 3 threads were occupying 100% CPU time each for 10 seconds until the 'after forkIO' was emitted. So what is happening here exactly, why do the 3 remaining HECs busy-wait during that FFI call instead of continuing the execution of the main thread? Do *all* foreign unsafe ccalls (even short ones) cause N-1 HECs to spend time in some kind of busy looping? [1]: http://blog.ezyang.com/2010/07/safety-first-ffi-and-threading/ Cheers, hvr

2 2

Simplifying Core pretty-printing via GHC API?
by Conal Elliott 02 May '13

02 May '13

I'm using the GHC API to compile Haskell source code to Core. I'd like to pretty-print the result with the sort of simplifications I get with -dsuppress-type-applications, -dsuppress-uniques, etc (used in combination with -ddump-simpl on ghc's command line). How can I set these options via the GHC API? Has the answer changed since 7.4.1 (which I'm currently using)? Thanks. - Conal

2 2

ANNOUNCE: GHC version 7.6.3
by Ian Lynagh 25 Apr '13

25 Apr '13

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.6.3 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3. This is a bugfix release relative to 7.6.2, so we recommend upgrading. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

3 2

Re: porting to uClibc-based 686 Linux
by Dubiousjim 21 Apr '13

21 Apr '13

On Wed, Apr 17, 2013 at 11:18:52PM +0100, Ian Lynagh wrote: > On Fri, Apr 05, 2013 at 11:12:38PM -0400, Dubiousjim wrote: > > target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs > > [1 of 1] Compiling Main ( hello.hs, hello.o ) > > Linking hello-cross ... > > target$ ./hello-cross > > Can't modify application's text section; use the GCC option -fPIE > > for position-independent executables. > > You can pass -fPIE to gcc by using the -optc-fPIE flag. > > Thanks > Ian Thanks Ian. There's much I don't fully understand about ghc, but I read somewhere that the -optc-* options would only be applied when building via intermediate C files, which isn't happening in the compilation process specified above. Is this incorrect, or have I misunderstood something? In any event, adding -optc-fPIE doesn't remove the error message. That error message is kicked up by uclibc, on account of the hello-cross binary having a TEXTREL section, which I understand it shouldn't have if we're generating PIE or PIC code. The instruction to "use the GCC option -fPIE" is just uclibc's suggestion as to how to avoid this. I also tried adding -fPIE or -fPIC to the "C compiler flags" section in inplace/lib/settings, but this didn't resolve the issue. I also tried using "BuildFlavour = unreg" in mk/build.mk, but this didn't resolve the issue. What I thought to try next is to add llvm/clang to my cross-compiler toolchain, and try building with the -fllvm flag in SRC_HC_OPTS. Other suggestions will be much welcomed. Thanks. -- dubiousjim(a)gmail.com

2 1

Re: Why is GHC so much worse than JHC when computing the Ackermann function?
by Edward Z. Yang 20 Apr '13

20 Apr '13

I don't seem to get the leak on latest GHC head. Running the program in GC debug mode in 7.6.2 is quite telling; the program is allocating *a lot* of megablocks. We probably fixed it though? Edward Excerpts from Mikhail Glushenkov's message of Sat Apr 20 01:55:10 -0700 2013: > Hi all, > > This came up on StackOverflow [1]. When compiled with GHC (7.4.2 & > 7.6.2), this simple program: > > main = print $ ack 4 1 > where ack :: Int -> Int -> Int > ack 0 n = n+1 > ack m 0 = ack (m-1) 1 > ack m n = ack (m-1) (ack m (n-1)) > > consumes all available memory on my machine and slows down to a crawl. > However, when compiled with JHC it runs in constant space and is about > as fast as the straightforward Ocaml version (see the SO question for > benchmark numbers). > > I was able to fix the space leak by using CPS-conversion, but the > CPS-converted version is still about 10 times slower than the naive > version compiled with JHC. > > I looked both at the Core and Cmm, but couldn't find anything > obviously wrong with the generated code - 'ack' is compiled to a > simple loop of type 'Int# -> Int# -> Int#'. What's more frustrating is > that running the program with +RTS -hc makes the space leak > mysteriously vanish. > > Can someone please explain where the space leak comes from and if it's > possible to further improve the runtime of this program with GHC? > Apparently it's somehow connected to the stack management strategy, > since running the program with a larger stack chunk size (+RTS -kc1M) > makes the space leak go away. Interestingly, choosing smaller stack > chunk sizes (256K, 512K) causes it to die with an OOM exception: > > $ time ./Test +RTS -kc256K > Test: out of memory (requested 2097152 bytes) > > > [1] http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with… >

3 2