May 2011 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Proposal to incorporate Haskell.org
by Don Stewart 16 Dec '11

16 Dec '11

Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) ------------------------------------------------------------------------ = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) <http://conservancy.softwarefreedom.org/>. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence <http://www.opensource.org/licenses/alphabetical>. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium <http://www.haskell.org/haskell-symposium/> and Industrial Haskell Group<http://industry.haskell.org/> webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation "The Haskell Foundation" was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed "community.haskell.org" in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation

4 5

MonoLocalBinds and hoopl
by Edward Z. Yang 19 Jun '11

19 Jun '11

Hello all, Here's an experience report for porting hoopl to manage MonoLocalBinds. The Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of code writing, along the lines of this: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block where f n = FF3 $ ff n m n = FF3 $ fm n l n = FF3 $ fl n FF3 f `cat` FF3 f' = FF3 $ f' . f f, m, l and cat are polymorphic functions that are only used once in the main expression, and are floated outside to improve readability. However, when MonoLocalBinds is turned on, these all become monomorphic and the definitions fail. In contrast, this (uglier) version typechecks: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) (FF3 . fl) (\(FF3 f) (FF3 f') -> FF3 $ f' . f)) block One suggestion that I had was that we should generalize local bindings that are only used once, but Marlow pointed out that this would make the typechecker more complex and I probably would agree. As a userspace developer, I have two options: 1. Bite the bullet and put in the polymorphic type signatures (which can be quite hefty) 2. Inline the definitions 3. Move the polymorphic functions into the global namespace (3) and (2) are not so nice because it breaks the nice symmetry between these definitions, which always define f, m, l for the many, many definitions in Hoopl of this style. Cheers, Edward

6 8

ghc cyclic import error confusing
by Evan Laforge 16 Jun '11

16 Jun '11

I've found ghc's cyclic import error to be rather confusing, and I finally took the time to understand why. Here's an example: Module imports form a cycle for modules: Cmd.Cmd (./Cmd/Cmd.hs) imports: Perform.Midi.Instrument Instrument.MidiDb Instrument.Db Perform.Midi.Instrument (./Perform/Midi/Instrument.hs) imports: Cmd.Cmd Instrument.MidiDb (./Instrument/MidiDb.hs) imports: Perform.Midi.Instrument Instrument.Db (./Instrument/Db.hs) imports: Instrument.Search Instrument.MidiDb Perform.Midi.Instrument Instrument.Search (./Instrument/Search.hs) imports: Instrument.MidiDb Perform.Midi.Instrument It seems to be in a strange order and mentions extraneous modules. I would find this much easier to read: Perform.Midi.Instrument -> Cmd.Cmd -> Instrument.MidiDb -> Perform.Midi.Instrument Instead, the order goes Cmd.Cmd -> Instrument.MidiDb, and then goes backwards to Perform.Midi.Instrument -> Cmd.Cmd. Then it goes forward again to Instrument.MidiDb -> Perform.Midi.Instrument. So the order makes you jump around if you want to trace the import chain. The duplicated module that joins the cycle is not visually highlighted. Whats more, it further confuses the eye by merging in multiple loops. I suppose it could be useful to include additional loops, but I would find it easier to read if they were included on their own line, such as: Cmd.Cmd -> Instrument.Db -> Instrument.Search -> Perform.Midi.Instrument -> Cmd.Cmd However, I think probably the shortest loop is the most interesting one, and if there are multiple shortest loops, simply picking one randomly is likely to be sufficient. Thoughts?

5 5

crash caused by generic visitor (?)
by Ranjit Jhala 09 Jun '11

09 Jun '11

Hi all, I'm trying to extract the set of identifiers that are read in given source file. To this end, I wrote the following code (full source at end.) ------------------------------------------------------------------------ main = do fname <- (!! 0) `fmap` getArgs tcm <- loadTypecheckedSource fname putStrLn $ showPpr tcm -- this works fine putStrLn $ showPpr $ allIds tcm -- this causes the crash return () allIds :: Data a => a -> [Id] allIds = listify (\x -> case (x :: Id) of _ -> True) ------------------------------------------------------------------------ and where: loadTypecheckedSource :: FilePath -> IO TypecheckedSource unfortunately, when I compile and run it, I get the dreaded: Bug: Bug: panic! (the 'impossible' happened) (GHC version 7.0.3 for i386-unknown-linux): placeHolderNames Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Turns out that the problem is when the file contains a type annotation. That is, ./Bug Test00.hs crashes, when Test00.hs is: module Test where x :: Int x = 0 but does not crash when the file is: module Test where x = 0 Can anyone tell me why listify chokes in the latter case? (And how one might get around the problem?) I include the full source below (compiled with: ghc --make Bug, using ghc 7.0.3) Thanks! Ranjit. ------------------------------------------------------------------------------------------------------ import GHC import Outputable import DynFlags (defaultDynFlags) import GHC.Paths (libdir) import System.Environment (getArgs) import Control.Monad import qualified Data.List as L import Data.Data import Data.Generics.Schemes (listify) main = do fname <- (!! 0) `fmap` getArgs tcm <- loadTypecheckedSource fname putStrLn $ showPpr tcm -- this works fine putStrLn $ showPpr $ allIds tcm -- this causes the crash return () allIds :: Data a => a -> [Id] allIds = listify (\x -> case (x :: Id) of _ -> True) loadTypecheckedSource :: FilePath -> IO TypecheckedSource loadTypecheckedSource fname = defaultErrorHandler defaultDynFlags $ runGhc (Just libdir) $ do df <- getSessionDynFlags setSessionDynFlags df tgt <- guessTarget fname Nothing setTargets [tgt] load LoadAllTargets res <- load LoadAllTargets if failed res then pprPanic "Load Failed!!" (text "AAARGH!") else tm_typechecked_source `fmap` getTypecheckedModule fname findModSummary :: GhcMonad m => FilePath -> m ModSummary findModSummary fname = do msums <- depanal [] False case L.find ((fname ==) . ms_hspp_file) msums of Just msum -> return msum Nothing -> pprPanic "ModuleName Lookup Failed!!" (text "AARGHC!") getTypecheckedModule :: GhcMonad m => FilePath -> m TypecheckedModule getTypecheckedModule = findModSummary >=> parseModule >=> typecheckModule

2 2

getCPUTime implementation incorrect?
by Evan Laforge 06 Jun '11

06 Jun '11

I've just noticed that getCPUTime is returning erratic results for me: GHCi, version 7.0.3: 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. Loading package filepath-1.2.0.0 ... linking ... done. Prelude> :m System.CPUTime Prelude System.CPUTime> getCPUTime 9696631700340362000000 Prelude System.CPUTime> getCPUTime 1333572622260398592000000 Prelude System.CPUTime> getCPUTime 21577331579851694000000 Prelude System.CPUTime> getCPUTime 21577331579861838000000 Prelude System.CPUTime> getCPUTime 1061231477620269514000000 Prelude System.CPUTime> getCPUTime 9965140170836829000000 This is ghc 7.0.3, OS X 10.6.7, and it's the x86_64 version downloaded from http://www.haskell.org/ghc/download_ghc_7_0_3 So, I looked at the CPUTime.hsc source in the base library, and it uses CTime to get tv_sec and tv_usec fields from the struct timeval. Unfortunately, and I never knew this, tv_usec is not time_t, but is suseconds_t. On my OS X, these are different types: time_t is 64 bits but suseconds_t is 32 bits. After writing my own getCPUTime that uses Int32 for tv_usec it's back to working again. But the proper way to do this is probably to introduce CSUSeconds (I'm guessing it stands for signed microseconds), which I guess means editing the autoconfig to put a new define in HsBaseConfig.h. I dont know anything about autoconfig, but it's probably easy enough for someone is :)

2 2

testsuite, failures galore
by Daniel Fischer 01 Jun '11

01 Jun '11

So my last testsuite run (validate --slow) with a new HEAD produced 651 unexpected failures :( Okay, the thing is that I forgot to add EXTRA_HC_OPTS=-optl-lz, see http://hackage.haskell.org/trac/ghc/ticket/3756 So, unless I miscounted, 611 of those were in way threaded1 due to: > Linking arrowrun001 ... > /usr/lib/gcc/i586-suse-linux/4.5/../../../libbfd.a(compress.o): In > function `bfd_uncompress_section_contents': > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:96:0: > undefined reference to `inflateInit_' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:106:0: > undefined reference to `inflateReset' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:103:0: > undefined reference to `inflate' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:108:0: > undefined reference to `inflateEnd' > > collect2: ld gab 1 als Ende-Status zurück > > *** unexpected failure for arrowrun001(threaded1) The ticket has low priority, but if anybody has an idea how to check whether libbfd depends on libz in the configure script, I'd appreciate it. Of the remaining 40 unexpected failures, 14 were due to the removal of datatype contexts (tcrun006 and tcrun029), 7 (tcrun007) were due to a parse error because -XGenerics does nothing anymore (so ghc couldn't parse "{|"), 3 due to a missing Show instance in dph. The remaining may or may not be serious, looking at them now.

3 10

Manipulating DynFlags importPaths
by Joshua Ball 30 May '11

30 May '11

Hi, What's the right way to alter the importPaths in the DynFlags? The following program freezes: -- requires ghc package import GHC import DynFlags ( defaultDynFlags ) main = defaultErrorHandler defaultDynFlags $ do runGhc (Just "/home/jball/lib/ghc-7.0.3") $ do dflags <- getSessionDynFlags let dflags = dflags { importPaths = ["/alt/path"] } setSessionDynFlags dflags I am using ghc 7.0.3, as you might have guessed. Josh "Ua" Ball

1 1

shared libraries on OS X
by John Lato 28 May '11

28 May '11

Hello, I recently tried to build ghc on OS X Snow Leopard as 64-bit with shared library support. I had to self-compile gmp and modify mk/build.mk (I later saw that Edward Amsden blogged about the same experience, http://blog.edwardamsden.com/2011/04/howto-install-ghc-703-on-os-x-64-bit.h…) and it seemed to work, but executables don't run. For example, with this small program: > import qualified Data.Vector.Unboxed as V > main = let vec = V.replicate 10 (1 :: Int) in print $ V.sum vec I get this result: Mac-1:~ johnlato$ ghc -O -dynamic foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... Mac-1:~ johnlato$ ./foo dyld: Library not loaded: /private/var/folders/aJ/aJF0t1uBF7WDCz1PZV0A0U+++TI/-Tmp-/vector-0.7.0.176669/vector-0.7.0.1/dist/build/libHSvector-0.7.0.1-ghc7.0.3.dylib Referenced from: /Users/johnlato/./foo Reason: image not found Trace/BPT trap It seems that dyld is looking into build folders for the libraries. If I set DYLD_LIBRARY_PATH before compiling it appears to work: Mac-1:~ johnlato$ export DYLD_LIBRARY_PATH=~/.cabal/lib/vector-0.7.0.1/ghc-7.0.3/:~/.cabal/lib/primitive-0.3.1/ghc-7.0.3/ Mac-1:~ johnlato$ ghc -O -dynamic foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... Mac-1:~ johnlato$ ./foo 10 This seems to be required for any libraries I've installed via cabal-install --user, which quickly becomes onerous. Could anyone give me some advice on how to make this work properly (e.g. without manually setting DYLD_LIBRARY_PATH)? Thanks, John

1 0

Dynamic linking in Windows GHC 7.0.3
by Hussain Sobhy 27 May '11

27 May '11

When using dynamic linking on windows, shared libraries seem to be stored in same folders where the packages where installed i.e each library in a different folder. And these folders aren't visible to the system (by the PATH variable). Is it possible to specify the folder to which the libraries (libHSrts-ghc8.03.dll etc.) will be stored ? for example C:\Windows\System32 Because currently when I try to run any executable which is dynamically linked it complains about missing dlls. Thanks

1 0