- Glasgow-haskell-users

Re: Modules and their explicit export lists (are an annoyance)
by Christian Höner zu Siederdissen 21 Jun '10

21 Jun '10

Thanks everybody for your thoughts. Based on what I've read this is what I will do: - fork a 'foreign' library, if I need to extend it substantially - export everything explicitly - or set namespaces like this: - Library (with the more stable interface) - Library.Internal (which exports everything) Because of the rather good versioning system of Cabal (like library=x.y.z) this seems to be the most practical solution for me. Though it still would be nice if I could inject functions into other peoples' namespaces -- so to speak ;-) Gruss, Christian * Christian Höner zu Siederdissen <choener(a)tbi.univie.ac.at> [19.06.2010 20:39]: > Hi everybody, > > I'd like some input on other peoples' thoughts on this. Recently, I > played around with a library that uses an explicit export list. While > there are reasons for having one: > > - efficiencey (inlining in the module) > - encapsulation > > in practice, it seems to me that they are more annoying than useful. For > once, it would think that ghc should produce efficient good across > modules with -O / -O2 anyway. > But the more important thing is, that it makes extending module > functionality a pain (eg. if a constructor is not exported using (..)). > > So, should I really fork a library just to be able to add a function? > > > > Btw. there are libraries, where an explicit export list is used, that > export the right amount of information. For example, in 'vector' enough > is exported to allow you to extend unboxed vectors. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Modules and their explicit export lists (are an annoyance)
by Christian Höner zu Siederdissen 20 Jun '10

20 Jun '10

Hi everybody, I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for having one: - efficiencey (inlining in the module) - encapsulation in practice, it seems to me that they are more annoying than useful. For once, it would think that ghc should produce efficient good across modules with -O / -O2 anyway. But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)). So, should I really fork a library just to be able to add a function? Btw. there are libraries, where an explicit export list is used, that export the right amount of information. For example, in 'vector' enough is exported to allow you to extend unboxed vectors.

7 7

Re: Modules and their explicit export lists (are an annoyance)
by Antoine Latter 19 Jun '10

19 Jun '10

Hi Christian, Is there a specific library you're having trouble with? One reason library authors can prefer explicit export lists is that they can hide implementation details, which can then make it easier to change in the future without breaking the users of the library. Antoine Cc'ing the haskell-cafe On Jun 19, 2010 1:39 PM, "Christian Höner zu Siederdissen" < choener(a)tbi.univie.ac.at> wrote: Hi everybody, I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for having one: - efficiencey (inlining in the module) - encapsulation in practice, it seems to me that they are more annoying than useful. For once, it would think that ghc should produce efficient good across modules with -O / -O2 anyway. But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)). So, should I really fork a library just to be able to add a function? Btw. there are libraries, where an explicit export list is used, that export the right amount of information. For example, in 'vector' enough is exported to allow you to extend unboxed vectors. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

ANNOUNCE: GHC 6.12.3 Release Candidate 1
by Ian Lynagh 17 Jun '10

17 Jun '10

Hi all, We are pleased to announce the first release candidate for GHC 6.12.3: http://www.haskell.org/ghc/dist/6.12.3-rc1/ As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

9 13

Re: How easy is it to build a GHC cross compiler targeting Windows?
by Simon Marlow 16 Jun '10

16 Jun '10

On 16/06/2010 15:38, MH wrote: > I have installed SUSE-10.2 with all mingw packages in my Virtualbox and > ready to start working. Would it be possible to provide a quick step by > step overview of what should be done? I've never done anything of that > sort and have no idea where to start. You would start with perl boot ./configure --build=i386-unknown-linux --host=i386-unknown-mingw32 --target=i386-unknown-mingw32 --with-gcc=something and then see what breaks. We probably don't distinguish between the host platform gcc and the cross-compiler gcc in the build system, that will probably cause difficulties. Cheers, Simon

1 0

What does interruptibility mean exactly?
by Bas van Dijk 16 Jun '10

16 Jun '10

Hello, I've a short question about interruptible operations. In the following program is it possible for 'putMVar' to re-throw asynchronous exceptions even when asynchronous exception are blocked/masked? newEmptyMVar >>= \mv -> block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: "Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible..." Do I need to interpret this as: 1) 'putMVar' is always interruptible because it's an operation that has the ability to block. For example when applied to a full MVar. or: 2) 'putMVar' is only interruptible when it actually blocks and not interruptible when it is sure that it will not block. For example when applied to an empty MVar like in the given program. The reason I'm asking is that in my threads library[2] I previously applied 'putMVar' to an empty MVar to signal the termination of a thread. However due to some comments in the topic about "Asynchronous Exception Wormholes" I got a bit scared that 'putMVar' might throw exceptions even in the scope of a block. Because this could cause dead-locks in my threads library, I rewrote it using TMVars which don't have interruptible operations. However, I'm still not sure about the exact semantics so I would like to clear this up. Regards, Bas [1] http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Exce… [2] darcs get http://code.haskell.org/~basvandijk/code/threads/

4 5

laziness in `length'
by Serge D. Mechveliani 15 Jun '10

15 Jun '10

Dear people and GHC team, I have a naive question about the compiler and library of ghc-6.12.3. Consider the program import List (genericLength) main = putStr $ shows (genericLength [1 .. n]) "\n" where n = -- 10^6, 10^7, 10^8 ... (1) When it is compiled under -O, it runs in a small constant space in n and in a time approximately proportional to n. (2) When it is compiled without -O, it takes at the run-time the stack proportional to n, and it takes enormousely large time for n >= 10^7. (3) In the interpreter mode ghci, `genericLength [1 .. n]' takes as much resource as (2). Are the points (2) and (3) natural for an Haskell implementation? Independently on whether lng is inlined or not, its lazy evaluation is, probably, like this: lng [1 .. n] = lng (1 : (list 2 n)) = 1 + (lng $ list 2 n) = 1 + (lng (2: (list 3 n))) = 1 + 1 + (lng $ list 3 n) = 2 + (lng (3: (list 4 n))) -- because this "+" is of Integer = 2 + 1 + (lng $ list 4 n) = 3 + (lng $ list 4 n) ... And this takes a small constant space. Thank you in advance for your explanation, ----------------- Serge Mechveliani mechvel(a)botik.ru

4 5

Unexpected NoImplicitPrelude behaviour in GHCi (bug?)
by Philip K.F. Hölzenspies 15 Jun '10

15 Jun '10

Dear GHCers, I have been experimenting some more with environments for lab work for an FP intro course. One thing students tend to have difficulty with in the initial labs are the error messages including type classes, or any kind of more general type than they expected. I am trying to work around this, by supplying a "Number" type for the first lab and gradually increasing the complexity over the next few labs. To let all error messages be in terms of my type, I use the NoImplicitPrelude option in a LANGUAGE pragma. However, I find the behaviour of GHCi unexpected. I have reduced the problem to a small case that reproduces the bug. Here is my BugDemo module: {-# LANGUAGE NoImplicitPrelude #-} module BugDemo where import qualified Prelude as P newtype Number = N P.Integer fromInteger = N Look at the following sessions: [holzensp@ewi1043:work/FPPrac]% ghci BugDemo.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling BugDemo ( BugDemo.hs, interpreted ) Ok, modules loaded: BugDemo. *BugDemo> 5 5 *BugDemo> :t 5 5 :: (P.Num t) => t *BugDemo> :q Leaving GHCi. [holzensp@ewi1043:work/FPPrac]% ghci -fno-implicit-prelude BugDemo.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling BugDemo ( BugDemo.hs, interpreted ) on the commandline: Warning: -fno-implicit-prelude is deprecated: use -XNoImplicitPrelude or pragma {-# LANGUAGE NoImplicitPrelude #-} instead Ok, modules loaded: BugDemo. *BugDemo> 5 <interactive>:1:0: Not in scope: `>>' *BugDemo> :t 5 5 :: Number *BugDemo> It's a bit awkward that I get an explicit warning about -fno-implicit-prelude being deprecated, while the behaviour is actually different. Obviously, when leaving out the definition for fromInteger, the second session fails whenever I type a number, whereas the first session behaves the same way. This seems to be me to be a bug. Kind regards, Philip

5 6

ANNOUNCE: GHC version 6.12.3
by Ian Lynagh 15 Jun '10

15 Jun '10

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.12.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.12.2, so we recommend upgrading. Release notes are here: http://darcs.haskell.org/download/docs/6.12.3/html/users_guide/release-6-12… How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://darcs.haskell.org/download/download_ghc_6_12_3.html 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; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. 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

Segmentation fault in non-dynamically linked binaries?
by austin seipp 15 Jun '10

15 Jun '10

Hello, I am running GHC on x86_64 debian linux, and recently I have discovered that the executables generated by my GHC segfault when the linking step is not dynamic. I discovered this while attempting to install haskell-src-exts, which requires a linked version of Setup.hs when cabal builds it (and which would fail inexplicably until I did further investigation.) Example: link ~/t » cat hi.hs main :: IO () main = putStrLn "hi" link ~/t » ghc -dynamic hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 => (0x00007fffbadff000) libHShaskell98-1.0.1.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/haskell98-1.0.1.1/libHShaskell98-1.0.1.1-ghc6.12.3.so (0x00007fab3a4c4000) libHSrandom-1.0.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/random-1.0.0.2/libHSrandom-1.0.0.2-ghc6.12.3.so (0x00007fab3a2af000) libHStime-1.1.4-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/time-1.1.4/libHStime-1.1.4-ghc6.12.3.so (0x00007fab39fad000) libHSprocess-1.0.1.3-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/process-1.0.1.3/libHSprocess-1.0.1.3-ghc6.12.3.so (0x00007fab39d93000) libHSdirectory-1.0.1.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/directory-1.0.1.1/libHSdirectory-1.0.1.1-ghc6.12.3.so (0x00007fab39b77000) libHSunix-2.4.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/unix-2.4.0.2/libHSunix-2.4.0.2-ghc6.12.3.so (0x00007fab398c6000) librt.so.1 => /lib/librt.so.1 (0x00007fab396a2000) libutil.so.1 => /lib/libutil.so.1 (0x00007fab3949f000) libdl.so.2 => /lib/libdl.so.2 (0x00007fab3929b000) libHSold-time-1.0.0.5-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/old-time-1.0.0.5/libHSold-time-1.0.0.5-ghc6.12.3.so (0x00007fab3903c000) libHSold-locale-1.0.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/old-locale-1.0.0.2/libHSold-locale-1.0.0.2-ghc6.12.3.so (0x00007fab38e28000) libHSfilepath-1.1.0.4-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/filepath-1.1.0.4/libHSfilepath-1.1.0.4-ghc6.12.3.so (0x00007fab38c07000) libHSarray-0.3.0.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/array-0.3.0.1/libHSarray-0.3.0.1-ghc6.12.3.so (0x00007fab38992000) libHSbase-4.2.0.2-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/base-4.2.0.2/libHSbase-4.2.0.2-ghc6.12.3.so (0x00007fab381f2000) libHSinteger-gmp-0.2.0.1-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/integer-gmp-0.2.0.1/libHSinteger-gmp-0.2.0.1-ghc6.12.3.so (0x00007fab37fe1000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fab37da1000) libHSghc-prim-0.2.0.0-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so (0x00007fab37b1c000) libHSrts-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/libHSrts-ghc6.12.3.so (0x00007fab378ba000) libm.so.6 => /lib/libm.so.6 (0x00007fab37637000) libHSffi-ghc6.12.3.so => /usr/local/lib/ghc-6.12.3/libHSffi-ghc6.12.3.so (0x00007fab3742a000) libc.so.6 => /lib/libc.so.6 (0x00007fab370c9000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fab36eac000) /lib64/ld-linux-x86-64.so.2 (0x00007fab3a6cb000) link ~/t » ./a.out hi link ~/t » rm ./a.out *.hi *.o link ~/t » ghc hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 => (0x00007fffaafff000) librt.so.1 => /lib/librt.so.1 (0x00007fdf83d77000) libutil.so.1 => /lib/libutil.so.1 (0x00007fdf83b74000) libdl.so.2 => /lib/libdl.so.2 (0x00007fdf8396f000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fdf83730000) libm.so.6 => /lib/libm.so.6 (0x00007fdf834ae000) libc.so.6 => /lib/libc.so.6 (0x00007fdf8314c000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fdf82f30000) /lib64/ld-linux-x86-64.so.2 (0x00007fdf83f9c000) link ~/t » ./a.out [1] 7850 segmentation fault ./a.out link ~/t » gdb7.0 ./a.out 139 ↵ GNU gdb (GDB) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/a/t/a.out...done. (gdb) r Starting program: /home/a/t/a.out [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x000000000067b3c0 in strlen@@GLIBC_2.2.5 () (gdb) bt #0 0x000000000067b3c0 in strlen@@GLIBC_2.2.5 () #1 0x0000000000432dd7 in setFullProgArgv () #2 0x000000000043464d in hs_init () #3 0x000000000043478d in startupHaskell () #4 0x0000000000433d59 in real_main () #5 0x0000000000433e87 in hs_main () #6 0x00007ffff6fccc4d in __libc_start_main () from /lib/libc.so.6 #7 0x0000000000402d49 in _start () (gdb) What's interesting is that this occurs with all versions of GHC on my machine, which include: * GHC 6.12.1 * GHC 6.12.3 * GHC 6.13.20100426 Executables that were statically linked with GHC before this strange behavior started occurring appear to still work, i.e. xmonad & xmobar. I recently did an update of my machine with aptitude, but I would not think this would interfere with GHC. Does anybody have any ideas?

2 1