Re: GADT Type Checking GHC 6.10 versus older GHC

2008-11-28 Thread Dominic Steinitz
Ignore my last email. I was accidentally using The Glorious Glasgow Haskell Compilation System, version 6.9.20080616 Mind you I am still having problems just not the same ones. I'll report back later. Dominic. ___ Glasgow-haskell-users mailing list

RE: GADT Type Checking GHC 6.10 versus older GHC

2008-11-28 Thread Simon Peyton-Jones
| I also feel that the type errors given when working with existential | types, especially GADTs with existentials, are confusing. I think | | I am using existential types to test GADT code. See | http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no longer | works with 6.10.1. Really?

Re: GADT Type Checking GHC 6.10 versus older GHC

2008-11-28 Thread Dominic Steinitz
Simon Peyton-Jones wrote: | I also feel that the type errors given when working with existential | types, especially GADTs with existentials, are confusing. I think | | I am using existential types to test GADT code. See | http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no

RE: GADT Type Checking GHC 6.10 versus older GHC

2008-11-28 Thread Simon Peyton-Jones
| arbitrarySeq :: Sequence a - Gen RepSeqVal | arbitrarySeq Nil = | return (RepSeqVal Nil Empty) | arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) = | do u - arbitraryType t |us - arbitrarySeq ts |case u of | RepTypeVal a v - | case us of |

Re: GADT Type Checking GHC 6.10 versus older GHC

2008-11-28 Thread Dominic Steinitz
Simon Peyton-Jones wrote: | arbitrarySeq :: Sequence a - Gen RepSeqVal | arbitrarySeq Nil = | return (RepSeqVal Nil Empty) | arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) = | do u - arbitraryType t |us - arbitrarySeq ts |case u of | RepTypeVal

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

2008-11-28 Thread Simon Marlow
Markus Barenhoff wrote: On Thu 27.11 09:49, Simon Marlow wrote: Brandon S. Allbery KF8NH wrote: On 2008 Nov 26, at 9:30, Markus Barenhoff wrote: Because the ports seem not to get updated, I tried to compile ghc 6.10.1 under freebsd 7 on amd64 myself. For compiling I first used the ports ghc

Re: GHCi debugger status

2008-11-28 Thread Simon Marlow
Peter Hercek wrote: Simon Marlow wrote: A similar argument applies to keeping the dynamic stack. The problem with the dynamic stack is that it doesn't look much like you expect, due to tail-calls. Do you think people expect the tail-calls to add a stack frame to the dynamic stack or is

Re: cross module optimization issues

2008-11-28 Thread Neil Mitchell
Hi I've talked to John a bit, and discussed test cases etc. I've tracked this down a little way. Given the attached file, compiling witih SHORT_EXPORT_LIST makes the code go _slower_. By exporting the print_lines function the code doubles in speed. This runs against everything I was expecting,

Re: GHCi debugger status

2008-11-28 Thread Peter Hercek
Simon Marlow wrote: Peter Hercek wrote: Simon Marlow wrote: A similar argument applies to keeping the dynamic stack. The problem with the dynamic stack is that it doesn't look much like you expect, due to tail-calls. Do you think people expect the tail-calls to add a stack frame to the

Re: cross module optimization issues

2008-11-28 Thread John Lato
Neil, thank you very much for taking the time to look at this; I greatly appreciate it. One thing I don't understand is why the specializations are caused by print_lines. I suppose the optimizer can infer something which it couldn't otherwise. If I read this properly, the functions being

RE: cross module optimization issues

2008-11-28 Thread Simon Peyton-Jones
The $f2 comes from the instance Monad (IterateeGM ...). print_lines uses a specialised version of that instance, namely Monad (IterateeGM el IO) The fact that print_lines uses it makes GHC generate a specialised version of the instance decl. Even in the absence of print_lines you can

Re: cross module optimization issues

2008-11-28 Thread pepe
On 28/11/2008, at 15:46, Simon Peyton-Jones wrote: The $f2 comes from the instance Monad (IterateeGM ...). print_lines uses a specialised version of that instance, namely Monad (IterateeGM el IO) The fact that print_lines uses it makes GHC generate a specialised version of the

Re: cross module optimization issues

2008-11-28 Thread John Lato
Yes, this does help, thank you. I didn't know you could generate specialized instances. In fact, I was so sure that this was some arcane feature I immediately went to the GHC User Guide because I didn't believe it was documented. I immediately stumbled upon Section 8.13.9. Thanks to everyone

Re: cross module optimization issues

2008-11-28 Thread Neil Mitchell
Hi instance Monad m = Monad (IterateeGM el m) where {-# SPECIALISE instance Monad (IterateeGM el IO) #-} does that help? Yes. With that specialise line in, we get identical performance between the two results. So, in summary: The print_lines function uses the IterateeGM with IO as the

Re: GHCi debugger status

2008-11-28 Thread Isaac Dupree
Simon Marlow wrote: Claus Reinke wrote: Then how about my suggestion for selectively adding lexical scope to breakpoints? I'd like to be able to say :break loc/name {names} and have GHCi make the necessary changes to keep {names} available for inspection when it hits that breakpoint.