- Glasgow-haskell-users

Impredicative types error
by John Meacham 01 Feb '12

01 Feb '12

Hi, I am running into an issue where some code that compiled and worked under 6.12 is failing under 7.0, the offending code is class DeNameable a where deName :: Module -> a -> a getDeName :: Tc (DeNameable n => n -> n) getDeName = do mn <- asks (tcInfoModName . tcInfo) return (\n -> deName mn n) Tc is a plain typechecking monad and this returns a generic denaming function that can be used to turn haskell names back into human readable form before printing errors in jhc. I have the ImpredicativeTypes LANGUAGE feature turned on. the error I get under 7.0 is src/FrontEnd/Tc/Monad.hs:131:29: Couldn't match expected type `n -> n' with actual type `DeNameable n' In the second argument of `deName', namely `n' In the expression: deName mn n In the first argument of `return', namely `(\ n -> deName mn n)' John

2 1

Re: [Haskell-cafe] Some thoughts on Type-Directed Name
by Anthony Clayden 31 Jan '12

31 Jan '12

> There is an effort underway to make Haskell's Records > better. The discussion is ongoing on the ghc-users mail > list, ... > in the direction of making the most minimal changes > possible to achieve some simple record name-spacing. > > Thanks, > Greg Weber Thank you Greg, Yes I know, and I have been trying to follow along (intermittently). Thank you for your attempts to marshall the discussion. What would really, really help me is for someone to have a look at the 'solution' I posted to the difficulties SPJ saw with the SORF approach. (I ref'd it in my reply to Steve.) It seemed from my testing to address the needs. Since I got it working in GHC 7.2.1, there's a good chance it will need only "minimal changes" to implement (I'm thinking mostly syntactic sugar) -- providing of course that it is workable and generalisable enough. It could possibly benefit from some of the new Kind-level stuff in 7.4.1 (that SPJ used, but wasn't available to me at the time). I keep trying to make the time to write up the full proposal on the Wiki. I see it as a 'tweak' to SORF. Given that I'm supposed to have a day job, I'm reluctant to make time until/unless someone else double-checks whether I'm barking up the wrong tree. Anthony

3 2

ghc needs memory
by John Meacham 31 Jan '12

31 Jan '12

So... I knew that ghc was a memory hog.. but I am suddenly running into it dying with messages like the following: ghc: out of memory (requested 5997056753664 bytes) make[1]: *** [jhc] Error 1 Before I go out and find a machine with 6 terrabytes of RAM, I figured I'd post here first :) now the strange thing is, this started happening at the same time for both ghc 6.12.1 and 7.0.x (will report exact version later) so clearly something about my code is tickling ghc the wrong way. Though, ghc 7.0.x is slightly better in that it requests only one and a half terrabytes of ram :) Hmm.. I will try to track down a smaller test case, or narrow down what change caused it, but everything looks quite benign. I did recently add NoMonomorphismRestriction, NoMonoLocalBinds, and OverloadedStrings to my standard options, which is the only global change across the board I can think of... John

2 2

ghc-7.4.1-rc1 recompilation checking
by Christian Maeder 30 Jan '12

30 Jan '12

Hi, full recompilation with ghc-7.4.1-rc1 is already triggered by a changed "-o" option, which is inconvenient when creating different binaries with shared modules. (see below) It is no problem if I always omit the -o option and get binaries named like my input file, though. Can/should this behaviour of ghc-7.4 be relaxed? Cheers Christian -bash-3.00$ ghc B -o b [1 of 2] Compiling C ( C.hs, C.o ) [2 of 2] Compiling Main ( B.hs, B.o ) Linking b ... -bash-3.00$ ghc A -o a [1 of 2] Compiling C ( C.hs, C.o ) [2 of 2] Compiling Main ( A.hs, A.o ) Linking a ...

3 4

Error when deriving Typeable for associated type
by Bas van Dijk 30 Jan '12

30 Jan '12

Hello, Given the following program: ----------------------------------------------------------- {-# LANGUAGE DeriveDataTypeable, TypeFamilies #-} import Data.Typeable class C a where data T a :: * data MyType1 = MyType1 deriving Typeable data MyType2 = MyType2 deriving Typeable instance C MyType1 where data T MyType1 = A1 deriving (Typeable) instance C MyType2 where data T MyType2 = A2 deriving (Typeable) ----------------------------------------------------------- I get the following unexpected error: TF_Data.hs:12:34: Duplicate instance declarations: instance Typeable1 T -- Defined at TF_Data.hs:12:34 instance Typeable1 T -- Defined at TF_Data.hs:15:34 When looking at the output of -ddump-deriv I see that the following instance is generated: instance Typeable1 T where ... I would have expected that the following instances were generated instead: instance Typeable1 (T MyType1) where ... instance Typeable1 (T MyType2) where ... Is this a bug in GHC? Thanks, Bas

1 0

7.4.1-candidate-2
by Serge D. Mechveliani 29 Jan '12

29 Jan '12

Dear GHC team, I have tested ghc-7.4.0.20120126 on Linux Debian, i-386-like by the following tests. 1. Making it by ghc-7.4.0.20111219. 2. Making it by itself. 3. Making random-1.0.1.1. 4. Making and running the DoCon-2.12 test. 5. Making and running an example under DoCon-2.12 under -prof (one point of SCC, without careful investigation). It looks all right. Notes ----- Making each new ghc version now needs also re-make of Ramdom before making DoCon. In ghc-7.4.0.20111219 the minimal `-M' for the DoCon test running is -M2600k, In ghc-7.4.0.20120126 it is -M2400k; and the time is 3.6 sec instead of 3.8, and ghc-7.4.1 has the same measure results as ghc-7.4.0.20120126. Reards, ------ Sergei mechvel(a)botik.ru

1 0

Fwd: [Gtk2hs-users] GHC 7.4+ rts_evalIO
by Axel Simon 28 Jan '12

28 Jan '12

Dear ghc developers, there seems to be a change in the C functions of ghc. How do we fix this? Is there some guide as to what has changed? Thanks, Axel Begin forwarded message: > From: Andriy Polishchuk <andriy.s.polishchuk(a)gmail.com> > Date: 27. Januar 2012 03:36:50 MEZ > To: gtk2hs-users(a)lists.sourceforge.net > Subject: [Gtk2hs-users] GHC 7.4+ rts_evalIO > > Hello, I'm newbie in haskell, so didn't got success bumping package manually. With new GHC gtk does not build with the following error: > > System\Glib\hsgclosure.c:110:5: > warning: passing argument 1 of 'rts_evalIO' from incompatible pointer type > S:\prog\lang.haskell\ghc\lib/include/RtsAPI.h:202:6: note: expected 'struct Capability **' but argument is of type 'str > ct Capability *' > > Are there any simple workarounds or it's hard stuff and it's better for me to wait new release? > The reason I want to hack with new GHC is that on windows there is fixed bug with ghci that doesn't allow to interactively link related libraries. > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2_______________________________________… > Gtk2hs-users mailing list > Gtk2hs-users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users

2 2

Re: Records in Haskell
by Anthony Clayden 28 Jan '12

28 Jan '12

> On Thu, Jan 26, 2012 at 8:02 PM, AntC > <anthony_clayden(a)clear.net.nz> wrote: > > > Ryan Newton <rrnewton <at> gmail.com> writes: > > > > > > > > I admit I'm a big fan of polymorphic extension. But I > > don't love it enough > > for it to impede progress! > > > > Records proposals for Haskell have repeatedly foundered on > the rocks of extensibility. Meanwhile, it seems like > years of experience with field extensibility in OO > languages has shown that it's not an especially good idea, > with authors on programming practice militating for > information hiding instead. > > I don't think it's worth treading that path yet again in > Haskell. > > -Jan Jan, I agree we shouldn't try leaping forward to extensibility yet. I disagree that we should abandon any thoughts of it and produce a stopgap approach for records that won't ever be extensible. The 'proof of concept' I posted to the list last month http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298… already includes get and set over polymorphic records and polymorphic fields, I believe, which is half way there. I love Haskell for the way it learns from well-structured mathematical approaches -- in the way I feel OO doesn't. There is a well-structured mathematically sound approach for extensibility, as it happens. It dates back to 1969. It is the 'engine' behind large-scale programming systems all over the world every day. I do and have worked with a lot of them. It's called Relational Algebra, it's based on set theory, it's declarative - which should fit smoothly with Haskell. It has an operation to extend records called 'extend' (!). It has an operation to merge records called 'join'. It has an operation to concatenate records called 'cross-product' You'll probably know it by its 'awkward cousin' SQL. There are many reasons for hating SQL, and there are many reasons why it's a bad fit to OO -- especially because SQL is declarative. There are many reasons to go back to the better-founded mathematical basis that pre-dates SQL. AntC

1 0

Error when building cabal package with template haskell configured for profiling
by Bas van Dijk 27 Jan '12

27 Jan '12

Hello, I would like to profile a cabal package that contains template haskell code. However I get the following error: $ cabal configure --ghc-options="-O2 -prof -auto-all -caf-all" ... $ cabal build ... Dynamic linking required, but this is a non-standard build (eg. prof). You need to build the program twice: once the normal way, and then in the desired way using -osuf to set the object file suffix. What's the best way to solve this? Currently I do a cabal build -v and copy the ghc --make ... command line. Then I first build the program normally (without -prof) and then build it with -prof and -osuf p_o like the error messages suggests. This is annoying however. Is there a ticket for this bug? Bas

2 2

Re: parallelizing ghc
by John Lato 27 Jan '12

27 Jan '12

> From: Evan Laforge <qdunkan(a)gmail.com> > > On Wed, Jan 25, 2012 at 11:42 AM, Ryan Newton <rrnewton(a)gmail.com> wrote: >>> package list for me. ?The time is going to be dominated by linking, >>> which is single threaded anyway, so either way works. >> >> What is the state of incremental linkers? ?I thought those existed now. > > I think in some specific cases. I've heard there's a microsoft one? > It would be windows only of course. Is anyone using that with ghc? > > gold is supposed to be multi-threaded and fast (don't know about > incremental), but once again it's ELF-only. I've heard a few people > talking about gold with ghc, but I don't know what the results were. > > Unfortunately I'm on OS X, I don't know about any incremental or > multithreaded linking here. Neither do I. On my older machine with 2GB RAM, builds are often dominated by ld because it starts thrashing. And not many linkers target Mach-O. I've been toying with building my own ld replacement. I don't know anything about linkers, but I'd say at least even odds that I can do better than this. John L.

3 2