Re: type families not advertised for 6.8

Jean-Philippe Bernardy schrieb: On 10/17/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: | on I read: "we are | not advertising type equalities for 6.8". What does this mean? Is it | possible that type family support will be removed

RE: type families not advertised for 6.8

| > Absolutely not; quite the reverse. It means that some of the *code* for | type functions happens to be in the 6.8 release --- but that code has bugs. | It's only in 6.8 for our convenience (to avoid too great a divergence between | the HEAD and 6.8), but we do not plan to *support* type functi

Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate

Hi Claus, On Wed, Oct 17, 2007 at 04:19:03PM +0100, Claus Reinke wrote: > >The 6.8.1 release is very close now. We only intend to look at the bugs > >listed here: > > > >http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.1&order=priority > > - the

Re: bug in 6.8.1-candidate

Hi Serge, Thanks for the report! On Sun, Sep 30, 2007 at 07:13:47PM +0400, Serge D. Mechveliani wrote: > > http://botik.ru/pub/local/Mechveliani/ghcBugs/bug-6.8.0-sep28.zip > > > ... > > GBasFld_.hs: ... > > ghc-6.8.0.20070928: panic! (

Re: type families not advertised for 6.8

On 10/17/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > | on I read: "we > are > | not advertising type equalities for 6.8". What does this mean? Is it > | possible that type family support will be removed from GHC at some point? >

Re: empty export warning

On Wed, Oct 17, 2007 at 03:35:37PM -0300, Isaac Dupree wrote: > Serge D. Mechveliani wrote: > >People, > > > >here is a more precise report about empty _export_ in > >ghc-6.8.1-candidate: > > > >I use > > > > module M1 (f, module M2) > > where > > import M2 ()

Re: empty export warning

Serge D. Mechveliani wrote: People, here is a more precise report about empty _export_ in ghc-6.8.1-candidate: I use module M1 (f, module M2) where import M2 () f = ... in the situation when M1 imports some insta

Re: Prevent optimization from tempering with unsafePerformIO

Hi again, On 10/17/07, Bernd Brassel <[EMAIL PROTECTED]> wrote: > > May I suggest a third route that has the advantages of both your > > approaches. The backside is of course that it takes a bit of work. My > > suggestion is to do an effect analysis of your curry programs to > > identify the purel

Re: Orphan Instances with GHC 6.8

Hello Simon Simon Peyton-Jones wrote: What you say rings no bells. I don't see how to make progress without more info. Perhaps show the module that elicits the unexpected orphan message? The problem I'm having is with collections-package.. http://darcs.haskell.org/packages/collections-ghc6.

empty export warning

People, here is a more precise report about empty _export_ in ghc-6.8.1-candidate: I use module M1 (f, module M2) where import M2 () f = ... in the situation when M1 imports some instances from M2 and reexports

RE: type families not advertised for 6.8

| on I read: “we are | not advertising type equalities for 6.8”. What does this mean? Is it | possible that type family support will be removed from GHC at some point? Absolutely not; quite the reverse. It means that some of the *code*

type families not advertised for 6.8

Hello, on I read: “we are not advertising type equalities for 6.8”. What does this mean? Is it possible that type family support will be removed from GHC at some point? Best wishes, Wolfgang __

RE: Orphan Instances with GHC 6.8

What you say rings no bells. I don't see how to make progress without more info. Perhaps show the module that elicits the unexpected orphan message? Simon | -Original Message- | From: Adrian Hey [mailto:[EMAIL PROTECTED] | Sent: 17 October 2007 17:04 | To: glasgow-haskell-users@haskell.

Re: Orphan Instances with GHC 6.8

Hello again, Adrian Hey wrote: Hello Folks, One thing different from 6.6 and 6.8 is I find that with -Wall I get a lot more warnings about orphan instances, even if the code has not changed. Has the definition of what an Orphan instance is changed? Or is this a bug? If so, is the bug in 6.6 o

Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate

The 6.8.1 release is very close now. We only intend to look at the bugs listed here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.1&order=priority so if you think there is something important that is not listed there then this is the time to

Re: Prevent optimization from tempering with unsafePerformIO

Bernd Brassel wrote: * I'm not sure if you care whether they are performed once or many times. E.g. f = \x. x + unsafePerformIO (h z) If the (h z) doesn't mention 'x', GHC will transform this to v = unsafePerformIO (h z) f = \x. x+v So now the effe

ANNOUNCE: GHC 6.8.1 Second Release Candidate

We are pleased to announce the Second Release Candidate phase for GHC 6.8.1. The 6.8.1 release is very close now. We only intend to look at the bugs listed here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.1&order=priority so if you th

Orphan Instances with GHC 6.8

Hello Folks, One thing different from 6.6 and 6.8 is I find that with -Wall I get a lot more warnings about orphan instances, even if the code has not changed. Has the definition of what an Orphan instance is changed? Or is this a bug? If so, is the bug in 6.6 or 6.8? I can make them go away w

Prevent optimization from tempering with unsafePerformIO

> I think you'll find it useful to be explicit about what you are relying on. Yes, good point. > For example I think that if your program contains two calls > unsafePerformIO e1 > unsafePerformIO e2 > then > * You don't care about the *order* in which these are performed Right,

Prevent optimization from tempering with unsafePerformIO

> May I suggest a third route that has the advantages of both your > approaches. The backside is of course that it takes a bit of work. My > suggestion is to do an effect analysis of your curry programs to > identify the purely functional parts and compile them directly to pure > Haskell. The rest

RE: Prevent optimization from tempering with unsafePerformIO

I think you'll find it useful to be explicit about what you are relying on. For example I think that if your program contains two calls unsafePerformIO e1 unsafePerformIO e2 then * You don't care about the *order* in which these are performed * You do care that they are both p

Re: Prevent optimization from tempering with unsafePerformIO

Hi Bernd, Bernd Brassel wrote: Hi David, thank you! This is really useful information! I think it's the let floating (out) together with common subexpression elimination: > ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs [1 of 1] Compiling Main ( curry.hs, curr

Re: Prevent optimization from tempering with unsafePerformIO

On 10/17/07, Bernd Brassel <[EMAIL PROTECTED]> wrote: > > why do you want to do this unsafely, > > instead of just using 'length'? unsafePerformIO is a very slow > > function, remember) > > The big picture is that we generate programs like this example in order > to compile the functional logic la

Prevent optimization from tempering with unsafePerformIO

Hi David, thank you! This is really useful information! > I think it's the let floating (out) together with common subexpression > elimination: > > > ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs > [1 of 1] Compiling Main ( curry.hs, curry.o ) > Linking curry-no-cse

Re: Prevent optimization from tempering with unsafePerformIO

Hi Stefan! Thanks for your answer. Stefan O'Rear wrote: > Might I suggest, that the problem is your use of unsafePerformIO? Yes you might. And you are surely right. But not using it in this way is not an alternative. > why do you want to do this unsafely, > instead of just using 'length'? un