June 2001 - Glasgow-haskell-users

Seq ??
by Saswat Anand 04 Jun '01

04 Jun '01

In ghc-5.00.1, "seq (2/0) 3" gives 3. Should it not give error. Hugs does. Thanks, S

2 1

RE: Instance Declaration discrepancy
by Simon Peyton-Jones 04 Jun '01

04 Jun '01

You need -fallow-undecidable-instances as well. Simon | -----Original Message----- | From: Saswat Anand [mailto:iscp9157@nus.edu.sg] | Sent: 02 June 2001 10:13 | To: 'glasgow-haskell-users(a)haskell.org' | Subject: Instance Declaration discrepancy | | | | class MyShow a where | sh :: a -> String | | instance (Integral a) => Show a where | sh = "Integer " + show a | | Ghc 5.00.1 (with -fglasgow-exts) does not accept the above, | while hugs with extensions has no problem with this. Is it a bug? | | Thanks, | S | | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

Re: Instance Declaration discrepancy
by Saswat Anand 02 Jun '01

02 Jun '01

> I am sorry for the typos. It should have been > > instance (Integral a) => Show a where > sh a = "Integer " ++ (show a) > > > > class MyShow a where > sh :: a -> String > > instance (Integral a) => Show a where > sh = "Integer " + show a > > Ghc 5.00.1 (with -fglasgow-exts) does not accept the above, while hugs > with extensions has no problem with this. Is it a bug? > > Thanks, > S > > > > >

1 0

Instance Declaration discrepancy
by Saswat Anand 02 Jun '01

02 Jun '01

class MyShow a where sh :: a -> String instance (Integral a) => Show a where sh = "Integer " + show a Ghc 5.00.1 (with -fglasgow-exts) does not accept the above, while hugs with extensions has no problem with this. Is it a bug? Thanks, S

1 0

Weak pointers, garbage collection & deadlocks
by Manuel M. T. Chakravarty 02 Jun '01

02 Jun '01

While using weak pointers and concurrency together, I became convinced that before issuing the ``no threads to run: infinite loop or deadlock?'' error message, the RTS should perform a GC. The reason is that the GC may run some finalisers, which in turn may unlock some threads. The concrete scenario that I have is that I use a finaliser to close a stream when the handle that provides input to that stream dies. Now if the only other thread is a consumer of that stream that waits for it to close, then this thread can't run before the next GC is performed and runs the finaliser. Opinions? Cheers, Manuel

1 0