- Glasgow-haskell-users

default roles
by Richard Eisenberg 10 Oct '13

10 Oct '13

As you may have heard, /roles/ will be introduced with GHC 7.8. Roles are a mechanism to allow for safe 0-cost conversions between newtypes and their base types. GeneralizedNewtypeDeriving (GND) already did this for class instances, but in an unsafe way -- the feature has essentially been retrofitted to work with roles. This means that some uses of GND that appear to be unsafe will no longer work. See the wiki page [1] or slides from a recent presentation [2] for more info. [1] : http://ghc.haskell.org/trac/ghc/wiki/Roles [2] : http://www.cis.upenn.edu/~eir/papers/2013/roles/roles-slides.pdf I am writing because it's unclear what the *default* role should be -- that is, should GND be allowed by default? Examples follow, but the critical issue is this: * If we allow GND by default anywhere it is type-safe, datatypes (even those that don't export constructors) will not be abstract by default. Library writers would have to use a role annotation everywhere they wish to declare a datatype they do not want users to be able to inspect. (Roles still keep type-*un*safe GND from happening.) * If we disallow GND by default, then perhaps lots of current uses of GND will break. Library writers will have to explicitly declare when they wish to permit GND involving a datatype. Which do we think is better? Examples: The chief example demonstrating the problem is (a hypothetical implementation of) Set: > module Set (Set) where -- note: no constructors exported! > > data Set a = MkSet [a] > insert :: Ord a => a -> Set a -> Set a > ... > {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-} > module Client where > > import Set > > newtype Age = MkAge Int deriving Eq > > instance Ord Age where > (MkAge a) `compare` (MkAge b) = b `compare` a -- flip operands, reversing the order > > class HasSet a where > getSet :: Set a > > instance HasSet Int where > getSet = insert 2 (insert 5 empty) > > deriving instance HasSet Age > > good :: Set Int > good = getSet > > bad :: Set Age > bad = getSet According to the way GND works, `good` and `bad` will have the same runtime representation. But, using Set operations on `bad` would indeed be bad -- because the Ord instance for Age is different than that for Int, Set operations will fail unexpectedly on `bad`. The problem is that Set should really be abstract, but we've been able to break this abstraction with GND. Note that there is no type error in these operations, just wrong behavior. So, if we default to *no* GND, then the "deriving" line above would have an error and this problem wouldn't happen. If we default to *allowing* GND, then the writer of Set would have to include > type role Set nominal in the definition of the Set module to prevent the use of GND. (Why that peculiar annotation? See the linked further reading, above.) Although it doesn't figure in this example, a library writer who wishes to allow GND in the default-no scenario would need a similar annotation > type role Foo representational to allow it. There are clearly reasons for and against either decision, but which is better? Let the users decide! Discussion time: 2 weeks. Thanks! Richard

10 29

Linux deployment requirements for GHC-produced binaries
by Yitzchak Gale 09 Oct '13

09 Oct '13

We received a complaint from one of our customers that the Linux executable for one of our products - compiled using GHC - does not run because of libgmp not being installed on their server. This binary was compiled using GHC 7.4.2 (HP 2012.4.0.0). We hope to be migrating soon to GHC 7.6.3 (HP 2013.2.0.0.). Do GHC-compiled binaries have a dynamic dependence on libgmp? If so, what are the exact requirements we need to communicate to our customers? Does this limit what versions of Linux we can claim that our product supports? Are there similar requirements and limitations regarding GNU Readline? Thanks, Yitz

5 10

cabal upload -- error 404
by Christian Hoener zu Siederdissen 09 Oct '13

09 Oct '13

Hi everybody, Does anybody know what this means and how to resolve it? I have updated my hackage account and can upload via the web interface, just not via cabal. cabal config file is new as well. cabal upload -c dist/PrimitiveArray-0.5.2.0.tar.gz Checking dist/PrimitiveArray-0.5.2.0.tar.gz... Error: dist/PrimitiveArray-0.5.2.0.tar.gz: 404 Not Found Sorry for this being the wrong mailing list ;-) Many thanks, Christian

2 1

RTS option -A affecting cpu-core usage?
by Daniel Trstenjak 08 Oct '13

08 Oct '13

Hi all, I played around with a parallel algorithm and tried to get the GC time down by specifying the RTS option '-A'. But if I'm specifying '-A' than also the usage of the cpu-cores seems to change. Without '-A' I'm getting a total cpu-core usage of '4.44s', with '-A' I'm getting only '1.67s'. Any ideas? Greetings, Daniel Without '-A': ------------- dan@machine ~> ghc-mod-dev find showWindows +RTS -s -N4 XMonad.Util.XUtils 980,770,296 bytes allocated in the heap 552,122,168 bytes copied during GC 163,683,152 bytes maximum residency (11 sample(s)) 4,369,800 bytes maximum slop 280 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1690 colls, 1690 par 2.45s 0.66s 0.0004s 0.0024s Gen 1 11 colls, 10 par 0.98s 0.26s 0.0239s 0.1022s Parallel GC work balance: 18.06% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 1025 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 0.99s ( 0.83s elapsed) GC time 3.43s ( 0.93s elapsed) EXIT time 0.02s ( 0.02s elapsed) Total time 4.44s ( 1.78s elapsed) Alloc rate 995,571,064 bytes per MUT second Productivity 22.7% of total user, 56.5% of total elapsed gc_alloc_block_sync: 53552 whitehole_spin: 0 gen[0].sync: 75 gen[1].sync: 23678 With '-A': ---------- dan@machine ~> ghc-mod-dev find showWindows +RTS -s -N4 -A500m XMonad.Util.XUtils 979,761,872 bytes allocated in the heap 94,043,424 bytes copied during GC 118,609,784 bytes maximum residency (2 sample(s)) 2,844,808 bytes maximum slop 2196 MB total memory in use (0 MB lost due to fragmentati Tot time (elapsed) Avg pause Ma Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s Gen 1 2 colls, 1 par 0.47s 0.18s 0.0878s Parallel GC work balance: 57.02% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (616 converted, 0 overflowed, 0 dud, 0 GC'd, 409 fizzl INIT time 0.02s ( 0.02s elapsed) MUT time 1.16s ( 1.16s elapsed) GC time 0.47s ( 0.18s elapsed) EXIT time 0.02s ( 0.02s elapsed) Total time 1.67s ( 1.38s elapsed) Alloc rate 844,914,346 bytes per MUT second Productivity 70.8% of total user, 85.9% of total elapsed gc_alloc_block_sync: 33458 whitehole_spin: 0 gen[0].sync: 5372 gen[1].sync: 0

1 1

Desugaring do-notation to Applicative
by Simon Marlow 05 Oct '13

05 Oct '13

Following a couple of discussions at ICFP I've put together a proposal for desugaring do-notation to Applicative: http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo I plan to implement this following the addition of Applicative as a superclass of Monad, which is due to take place shortly after the 7.8 branch is cut. Please discuss here, and I'll update the wiki page as necessary. Cheers, Simon

13 14

carriage returns on Windows from quasi-quotes
by Greg Weber 05 Oct '13

05 Oct '13

A Windows user rerported using Data.Text.IO.writeFile to write out quasi-quoted text. writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns?

2 2

Trying to compile ghc HEAD on xubuntu 13.04-x64
by Nathan Hüsken 04 Oct '13

04 Oct '13

Hey, because I have touble with ghci and packages with FFI, it was suggested to me to compile and use ghc HEAD. I am on xubuntu 13.04 64bit and try to do a perf build. It fails with: compiler/ghc.mk:478: warning: ignoring old commands for target `compiler/stage2/build/libHSghc-7.7.20131004-ghc7.7.20131004.so' "/home/ls/src/ghc/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-O --optghc=-H64m --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /366) in 'GHC.PrimopWrappers' 72% (813 /1132) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20131004 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 make: *** [all] Error 2 Suggestions? Thanks! Nathan

3 2

RE: Desugaring do-notation to Applicative
by Neil Sculthorpe 02 Oct '13

02 Oct '13

While I really like applicative notation, sometimes naming intermediate results can make code a lot more readable. So I think supporting applicative do-notation would be beneficial. Neil On 02/10/13 07:00, p.k.f.holzenspies wrote: > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 2 Oct 2013 09:12:26 +0000 > From: <p.k.f.holzenspies(a)utwente.nl> > To: <iavor.diatchki(a)gmail.com>, <dag.odenhall(a)gmail.com> > Cc: marlowsd(a)gmail.com, glasgow-haskell-users(a)haskell.org, > simonpj(a)microsoft.com > Subject: RE: Desugaring do-notation to Applicative > Message-ID: > <E7F535B24A47D747A07D46C0AA82D43D0AB17531(a)EXMBX21.ad.utwente.nl> > Content-Type: text/plain; charset="utf-8" > > I thought the whole point of Applicative (at least, reading Connor?s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point *not* to resort to binds or do-notation. > > That being said, I?m all for something that will promote the use of the name ?pure? over ?return?. > > +1 for the Opt-In > > Ph. > >

1 0

openindiana binaries
by asyropoulos＠aol.com 30 Sep '13

30 Sep '13

Hello, This weekend I tried to compile ghc-7.6.3 on OpenIndiana using an older version that was posted at http://www.haskell.org/ghc/download_ghc_7_0_3 I have used this version to compile install pandoc and pandoc compiled just fine and it works! However, I have noticed that libffi.so.6 should not be installed in a non standard folder, and I have no idea if this is a problem of OpenIndiana or Solaris more generally. Now, I think it would be nice to add this version to the download page, do you know whom I have to contact for the relevant details? Regards, A.S. -- Apostolos Syropoulos Xanthi, Greece

2 2

Executables using GHC API require dynamic linking in GHC 7.7
by Christiaan Baaij 28 Sep '13

28 Sep '13

Dear all, It seems that executables that use the GHC API require to be dynamically linked on GHC 7.7. At least in the case that an GHC API function has to perform linking. Statically linked executable SEGFAULT when a GHC API function tries to do linking. I build 'haddock' from source by doing a 'cabal install' in the 'utils/haddock' directory of my ghc build tree. Here is the output of my statically linked haddock when I run it on one of my libraries: Haddock coverage: Warning: main:CLaSH.Util: Could not find documentation for exported module: X Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses 95% ( 18 / 19) in 'CLaSH.Util' 100% ( 8 / 8) in 'CLaSH.Core.TyCon' 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' 100% ( 5 / 5) in 'CLaSH.Core.DataCon' 100% ( 3 / 3) in 'CLaSH.Core.Literal' 100% ( 5 / 5) in 'CLaSH.Core.Var' Bus error: 10 <-- SEGFAULT Here is the output of my dynamically linked haddock when I run it on one of my libraries: Haddock coverage: Warning: main:CLaSH.Util: Could not find documentation for exported module: X Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses 95% ( 18 / 19) in 'CLaSH.Util' 100% ( 8 / 8) in 'CLaSH.Core.TyCon' 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' 100% ( 5 / 5) in 'CLaSH.Core.DataCon' 100% ( 3 / 3) in 'CLaSH.Core.Literal' 100% ( 5 / 5) in 'CLaSH.Core.Var' 100% ( 5 / 5) in 'CLaSH.Core.Term' 100% ( 8 / 8) in 'CLaSH.Core.Subst' 100% ( 24 / 24) in 'CLaSH.Core.Type' <… lots of warnings about missing link destination … > ~/Documents/devel/clash/src (master *)$ I believe that the use of TH in the CLaSH.Core.Var file triggers the segfault in the statically linked version. I'm trying to create a smaller test case than running haddock on my library, but have been unsuccessful so far. That is why I haven't posted a bug report on the bug tracker yet. If somebody thinks I should, then please say so :-) My platform is: OS: OS X 10.8.5 XCode: X-Code CL-tools 4.6.2 GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546) Build.mk: SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 HADDOCK_DOCS = NO I hope somebody can test this on linux with dynamic linking. As this bug affects haddock, I think it is quite important that somebody with more knowledge of dynamic linking looks into this. Regards, Christiaan

2 1