December 2011 - Glasgow-haskell-users

renamed GMP symbols in GHC
by Michal Konečný 09 Jan '12

09 Jan '12

Dear all, Several issues related to the way GMP is included in GHC were publicly discussed in the past with the goal of replacing GMP. As summarised in this wiki by Peter Tanski, the main issues were: (1) Licensing (2) Memory Structure; Simultaneous Access to GMP by Foreign (C) code in the Same Binary. My immediate concern is (2) as I develop programs that link with MPFR, which uses GMP. So far I got around the issue by compiling GHC with integer-simple. This is fine for me but I feel the need to recompile ghc may be hindering some people who would like to try my software that links with MPFR. I have therefore been looking for a way to overcome (2) that could make it to the default build of GHC. As suggested by Simon PJ in this email, a simple way to deal with issue (2) is to "*copy* GMP, changing all the function names". I recently found some time and had a go at implementing this suggestion and it turned out to be quite easy. I described my recipe to do such a "copy" here but currently I have been able to test it only on x86 Linux and GHC 7.2.1. I checked that the renaming makes a difference by running all QuickCheck tests of my AERN-Real-MPFR package. Some of these tests persistently fail when compiled with a standard GHC. All tests succeed with GHC/integer-simple and also with GHC 7.2.1 using the renamed GMP. I was wondering whether such a change (more polished and tested on all common platforms) could make it to the future official GHC releases. If the GHC developers would support this change, I would be happy to put more work into it. I think the following concrete changes would be required in the GHC distribution: (a) make a ghc build always use the bundled GMP (b) apply a renaming script onto the GMP tar before adding it to the GHC source bundle (c) rename symbols analogously in integer-gmp/cbits/* An alternative to (b) is to apply the renaming to the GMP sources just before building it. One thing I am not clear about is the impact such a change would have on lincensing. My understanding is that GHC sources include GMP sources and in the absence of an installed GMP library, they are statically linked into the integer-gmp package. (Does it mean that the integer-gmp package should be LGPL lincensed?) The suggested changes would mean that this kind of linking would happen always, not only when no other GMP library is available on the system. In either case, it seems to me that using integer-gmp as a shared library would still be OK for producing non-LGPL code. I would be grateful for your views and guidance. Best regards, Michal -- |o| Michal Konecny <mikkonecny(a)gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston

9 20

ConstraintKinds and default associated empty constraints
by Bas van Dijk 09 Jan '12

09 Jan '12

I'm playing a bit with the new ConstraintKinds feature in GHC 7.4.1-rc1. I'm trying to give the Functor class an associated constraint so that we can make Set an instance of Functor. The following code works but I wonder if the trick with: class Empty a; instance Empty a, is the recommended way to do this: {-# LANGUAGE ConstraintKinds, TypeFamilies, FlexibleInstances #-} import GHC.Prim (Constraint) import Prelude hiding (Functor, fmap) import Data.Set (Set) import qualified Data.Set as S (map, fromList) class Functor f where type C f :: * -> Constraint type C f = Empty fmap :: (C f a, C f b) => (a -> b) -> f a -> f b class Empty a; instance Empty a instance Functor Set where type C Set = Ord fmap = S.map instance Functor [] where fmap = map testList = fmap (+1) [1,2,3] testSet = fmap (+1) (S.fromList [1,2,3]) Cheers and thanks for a great new feature! Bas

9 22

7.4.1-pre: Show & Integral
by Serge D. Mechveliani 08 Jan '12

08 Jan '12

пDear GHC team, ghc-7.0.1 assumes that Integral includes Show, and ghc-7.4.0.20111219 does not assume this. Which one agrees with Haskell-2010 ? Regards, ------ Sergei mechvel(a)botik.ru

5 4

filename corruption with -osuf in ghc-7.0.3
by Evan Laforge 04 Jan '12

04 Jan '12

I've noticed a strange behaviour with ghc's -osuf flag: % cat >Test.hs {-# LANGUAGE ForeignFunctionInterface #-} module Test where import Foreign foreign import ccall "wrapper" c_callback :: Int -> IO (FunPtr Int) % ghc-7.0.3 -v -c -osuf .hs.o Test.hs % ls Tes_stub.hs.o Test.hs Test_stub.c Test.hi Test.hs.o Test_stub.h Notice that the .o for the _stub.c has acquired the .hs.o suffix, but the last 't' of 'Test' was chopped off. I tried the same test with the latest ghc-7.4, and it doesn't generate a Test_stub.c at all, though there is a Test_stub.h. But I guess it sidesteps the question of whether -osuf should apply to the _stub.c (I feel like it shouldn't, since it's a c file compiled by cc, not by ghc). I'm curious about why ghc no longer seems to need _stub.c files. I'd test in more details, but runghc ghci for 7.4 is segfaulting unpredictably so I think there are larger problems here.

2 2

ghc-cabal-Random
by Serge D. Mechveliani 02 Jan '12

02 Jan '12

People, I have ghc-7.4.0.20111219 made from source and tested it on the DoCon-2.12 application -- thanks to people for their help! It looks all right. This was -- with skipping the module Random. Now it remains to add the Random package. I have taken AC-Random Version 0.1 from hackage. Its installation requires Cabal: > which cabal cabal: Command not found. > And Cabal is difficult to install, it reports that such and such package versions are missing. On the other hand, Cabal is, probably, present inside ghc-7.4.0.20111219, somewhere in the installation directory. Thus I see its .a and .o files in ~/ghc/7.4.1pre/inst0/lib/ghc-7.4.0.20111219/Cabal-1.14.0/ Can you, please, tell me what is the simplest way to install Random in this situation? Thank you in advance for your explanation, ------ Sergei mechvel(a)botik.ru

6 8

7.4.1-cand for docon
by Serge D. Mechveliani 31 Dec '11

31 Dec '11

Dear GHC team, The archive http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc741candQuest.zip contains the source of the docon-2.12 application. ghc-7.0.1 compiles it and runs the test successfully. ghc-7.4.0.20111219 cannot compile it. 1. It requires to add Show a to Integral a in a certain place. It occurs that this requirement breaks the standard (?). But all right, so far, add Show a there and see what happens further. 2. It reports that certain two packages overlap at some module. This is a matter of the `build-depends' field in docon.cabal and of the import declarations. I tried to correct the build-depends list. But each time the compiler reports that a) some packages overlap or b) build-depends has a wrong line or c) it cannot find some module (for example, Random). Can you please, look into ghc741candQuest.zip and set there an appropriate build-depends ? (so that make configure make build make install finish correctly). How does the user guess of this list, what is the method? This also touches the question of the module Random ------------- Thorkil Naur <naur(a)post11.tele.dk> wrote > System.Random can be found in http://hackage.haskell.org/package/random. I do not find the Random class in Haskell-2010. Probably, DoCon imports Random from the GHC (non-standard) library. When installing ghc-7.01, I just download the source distribution, `make' it, and it installs automatically together with the module Random. Has the status of the module Random changed in ghc-7.4.1 ? What is a regular way to install ghc-7.4.1 together with the module Random ? 3. After the point (2) is fixed, there may appear some more of them ... Thank you in advance for your explanation, ------ Sergei mechvel(a)botik.ru

3 2

"GeneralizedNewtypeDeriving"
by Matthew Farkas-Dyck 27 Dec '11

27 Dec '11

Just of curiosity, why is it spelt with a z? Is it spelt thus in Scottish English? I thought that "generalised" is written throughout Great Britain. Cheers, MFD

3 3

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
by Joachim Breitner 24 Dec '11

24 Dec '11

Hi, Am Samstag, den 24.12.2011, 08:28 +1100 schrieb Erik de Castro Lopo: > Joachim Breitner wrote: > > > ghc-stage2: panic! (the 'impossible' happened) > > (GHC version 7.4.0.20111219 for powerpc-unknown-linux): > > Cant do annotations without GHCi > > {libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} > > base:GHC.Exts.ForceSpecConstr{d rbL} > > Thats related to the problem of GHCi being broken on powerpc. Somewhat: vector uses annotations, annotation need GHCi, GHCi is disabled (because broken) on powerpc, vector is bundled by accident in GHC (and will be removed in the final release, unless I am mistaken), and the real vector package is patched in Debian to handle this (http://patch-tracker.debian.org/patch/series/view/haskell-vector/0.9-2/no_a…) My hope is that ghc will in the future ignore annotations on non-GHCi-arches (http://hackage.haskell.org/trac/ghc/ticket/4268) Once vector is unbundled, I expect the build to succeed on powerpc. I guess the other weird-arch builds would have failed at this point as well, if they had not failed due to the various other reasons earlier; I hope these get fixed in the final release. Maybe Debian should offer GHC to run buildbots (http://hackage.haskell.org/trac/ghc/wiki/Builder) on at least some of our weird arch machines, so that these problems will be noticed. earlier. But I’m not sure if the DSA team allows such a thing, as we’d be running code that is not under our control. Is someone in the Haskell team interested in finding that out? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Show and Integral
by Serge D. Mechveliani 23 Dec '11

23 Dec '11

Sorry, I have forgotten to copy to the List my last note on this subject. The on-line spec of Haskell-2010 shows Eq Show \ / Num | Real | Integral Hence, for x :: Integral a => a, it is correct to apply (show x). And ghc-7.4.0.20111219 does not allow this (show x). So, it breaks the standard, and people say, this is deliberate. I witness such a break for the first time, and this looks so strange! Well, I also diskile the edge Show / Num in the standard. But it is better to implement Show as dummy for appropriate types, -- so far, -- and to wait for the next standard. Am I missing something? Regards, ------ Sergei mechvel(a)botik.ru

1 0

Re: Unit unboxed tuples
by Christian Höner zu Siederdissen 23 Dec '11

23 Dec '11

Hi, I have to second that. I recently "fell" over that problem when writing instances for certain kinds of tuples. In libraries, such as "tuple" there is a special 'OneTuple' constructor but I'd really appreciate a more uniform fix -- but don't know of one either... Gruss, Christian * Ganesh Sittampalam <ganesh(a)earth.li> [23.12.2011 15:39]: > On 23/12/2011 13:46, Ian Lynagh wrote: > > On Fri, Dec 23, 2011 at 01:34:49PM +0000, Simon Peyton-Jones wrote: > >> > >> Arguments Boxed Unboxed > >> 3 ( , , ) (# , , #) > >> 2 ( , ) (# , #) > >> 1 > >> 0 () (# #) > >> > >> Simple, uniform. > > > > Uniform horizontally, but strange vertically! > > It's worth mentioning that if you want to write code that's generic over > tuples in some way, the absence of a case for singletons is actually a > bit annoying - you end up adding something like a One constructor to > paper over the gap. But I can't think of any nice syntax for that case > either. > > Cheers, > > Ganesh > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0