August 2004 - Glasgow-haskell-users

RE: Lazy type-class resolution
by Simon Peyton-Jones 13 Aug '04

13 Aug '04

just overlap I think | -----Original Message----- | From: Tomasz Zielonka [mailto:t.zielonka@students.mimuw.edu.pl] | Sent: 13 August 2004 11:50 | To: Simon Peyton-Jones | Cc: GHC-users | Subject: Re: Lazy type-class resolution | | On Fri, Aug 13, 2004 at 09:03:53AM +0100, Simon Peyton-Jones wrote: | > Yes, when *inferring* types GHC defers context reduction as long as | > possible. Reason: the call site of the function may "see" more instance | > declarations (e.g. in particular, overlapping ones), so doing reduction | > later may yield a different answer. | | Thanks for explanation. | | Besides overlapping instances, what are the other mechanisms that could | change the decision later? I can't think of any, are they only | hypotetical? | | Best regards, | Tom | | -- | .signature: Too many levels of symbolic links

1 0

RE: Lazy type-class resolution
by Simon Peyton-Jones 13 Aug '04

13 Aug '04

Yes, when *inferring* types GHC defers context reduction as long as possible. Reason: the call site of the function may "see" more instance declarations (e.g. in particular, overlapping ones), so doing reduction later may yield a different answer. When checking the inferred type against a programmer-supplied type signature, none of this applies; GHC looks for a proof "on the spot" that the inferred constraints are derivable from the signature. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Tomasz Zielonka | Sent: 12 August 2004 21:44 | To: GHC-users | Subject: Lazy type-class resolution | | Hello! | | Recently I was trying to write a variadic function composition operator in | Haskell. I managed to produce a version with such an interface: | | runF (compose f1 f2 f3 ... fn) == f1 . f2 . f3 . ... . fn | | I believe it is impossible to remove 'runF' without loosing generality | and introducing ambiguities. | | But that's not my question. I noticed that Hugs can instantly infer the nice | type for result of composition, but GHC keeps the huge typeclass context to | the last moment. | | __ __ __ __ ____ ___ _________________________________________ | || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard | ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2003 | ||---|| ___|| World Wide Web: http://haskell.org/hugs | || || Report bugs to: hugs-bugs(a)haskell.org | || || Version: November 2003 _________________________________________ | | Hugs mode: Restart with command line option +98 for Haskell 98 mode | | Type :? for help | Prelude> :l Comp | Comp> :t runF (compose succ (+ 1) succ read) | runF (compose succ (flip (+) 1) succ read) :: (Num a, Enum a, Read a) => [Char] -> a | Comp> :t runF (compose id id id id) | runF (compose id id id id) :: a -> a | | ___ ___ _ | / _ \ /\ /\/ __(_) | / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. | / /_\\/ __ / /___| | http://www.haskell.org/ghc/ | \____/\/ /_/\____/|_| Type :? for help. | | Loading package base ... linking ... done. | Prelude> :l Comp | Compiling Comp ( Comp.hs, interpreted ) | Ok, modules loaded: Comp. | *Comp> :t runF (compose succ (+ 1) succ read) | runF (compose succ (+ 1) succ read) :: | forall a b a1 a2 a3 a4. | (MkComp (a1 -> a1) | ((a2 -> a2) | -> (a3 -> a3) -> (String -> a4) -> F a b), | Enum a1, | Num a2, | Enum a3, | Read a4) => | a -> b | *Comp> runF (compose succ (+ 1) succ read) "13123" :: Int | 13126 | *Comp> :t runF (compose id id id id) | runF (compose id id id id) :: | forall a b a1 a2 a3 a4. | (MkComp (a1 -> a1) ((a2 -> a2) -> (a3 -> a3) -> (a4 -> a4) -> F a b)) => | a -> b | *Comp> let f = runF (compose id id id id) | *Comp> :t f | f :: forall b. b -> b | | Is this a known feature of GHC ? | | Best regards, | Tom | | -- | .signature: Too many levels of symbolic links | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Re: Lazy type-class resolution
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

Yes, lazy type-class resolution is a known GHC feature - and in my opinion much superior to Hugs stict type class resolution. Hugs can get confused with overlapping instances and will choose the wrong instance because it commits too early. GHC does not suffer from this. Keean.

1 0

Lazy type-class resolution
by Tomasz Zielonka 12 Aug '04

12 Aug '04

Hello! Recently I was trying to write a variadic function composition operator in Haskell. I managed to produce a version with such an interface: runF (compose f1 f2 f3 ... fn) == f1 . f2 . f3 . ... . fn I believe it is impossible to remove 'runF' without loosing generality and introducing ambiguities. But that's not my question. I noticed that Hugs can instantly infer the nice type for result of composition, but GHC keeps the huge typeclass context to the last moment. __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2003 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: November 2003 _________________________________________ Hugs mode: Restart with command line option +98 for Haskell 98 mode Type :? for help Prelude> :l Comp Comp> :t runF (compose succ (+ 1) succ read) runF (compose succ (flip (+) 1) succ read) :: (Num a, Enum a, Read a) => [Char] -> a Comp> :t runF (compose id id id id) runF (compose id id id id) :: a -> a ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :l Comp Compiling Comp ( Comp.hs, interpreted ) Ok, modules loaded: Comp. *Comp> :t runF (compose succ (+ 1) succ read) runF (compose succ (+ 1) succ read) :: forall a b a1 a2 a3 a4. (MkComp (a1 -> a1) ((a2 -> a2) -> (a3 -> a3) -> (String -> a4) -> F a b), Enum a1, Num a2, Enum a3, Read a4) => a -> b *Comp> runF (compose succ (+ 1) succ read) "13123" :: Int 13126 *Comp> :t runF (compose id id id id) runF (compose id id id id) :: forall a b a1 a2 a3 a4. (MkComp (a1 -> a1) ((a2 -> a2) -> (a3 -> a3) -> (a4 -> a4) -> F a b)) => a -> b *Comp> let f = runF (compose id id id id) *Comp> :t f f :: forall b. b -> b Is this a known feature of GHC ? Best regards, Tom -- .signature: Too many levels of symbolic links

1 1

Closed Classes...
by MR K P SCHUPKE 12 Aug '04

12 Aug '04

Been having a bit of a discussion in the Cafe... Just wondered what GHC specific issues would be involved with assuming all classes are closed. I am thinking that there is no real dis-advantage to considering all classes closed within their current context (IE all the imports to the current module). It seems to me that the argument about breaking code is wrong, as any changes to modules not imported into this module cannot have any affect on the code in this module. The only changes that can affect this module are changes to modules imported into this module - which of course can break things in many ways (like changing the type of a function)... In other words when the instances visible in a module change - all modules importing that module need to be recompiled (which is what happens when you use 'make' anyway). Can somebody either convince me their is a real problem with the 'closed' assumption, otherwise can GHC be changes to do this? Maybe an intermediate step would be to have a command line flag (-fall-closed ?) Keean.

1 0

RE: Network, sClose
by Bayley, Alistair 12 Aug '04

12 Aug '04

> -----Original Message----- > From: Glynn Clements [mailto:glynn.clements@virgin.net] > > However, even if sClose was exported, that wouldn't be of any > help in Jon's case, as neither of the sockets which recvFrom > creates are visible outside of recvFrom. Ahh, OK. I haven't used recvFrom/sendTo yet... (trying it now) ... When I try Jon's example with 6.2.1 (Win XP) I don't get the same error; it works twice and then hangs (my networking code would hang if I tried to re-use a socket that hadn't been properly closed). Is recvFrom meant to be a one-shot function i.e. the socket is only closed when the process exits? Jon's second example uses listenOn/accept and handles, which is also what I used: > do sock <- listenOn$PortNumber 7607; (hdl,host,port)<- accept sock; > s<-IO.hGetContents hdl; putStr$s; IO.hClose hdl; Network.Socket.sClose > sock Network.Socket.sClose is obviously useful here, so don't you think it would be a good idea to put it in Network? I don't see why including sClose would imply that you should start exposing other low-level stuff. AFAICT, it is the one little thing that's missing from Network that makes writing simple networking code possible. There's a lack of symmetry (closure?): you can create a socket with Network.listenOn, but there is no corresponding close function in Network. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

5 5

RE: GHCI/FFI/GMP/Me madness
by Simon Marlow 11 Aug '04

11 Aug '04

On 10 August 2004 16:04, Remi Turk wrote: >> - reset GMP's memory allocators before calling it from your code, >> and set them back to the RTS allocators afterward. Slow, but it >> should work. It doesn't solve the problem properly though: >> external libraries which use GMP are still broken. > It does indeed seem to work, after a quick test. (new util.c attached) > > And it does solve _my_ immediate "problem": I can surround every > gmp-operation with a gmp_begin()/gmp_end() and pretend to be > happy. (and anyway, I'm just messing around, failure merely means > I've got yet another unfinished project ;)) > > Part of the reason for all this messy FFIing is your post: > http://www.haskell.org/pipermail/glasgow-haskell-users/2004-June/006767. html Hmm yes, I now realise that it's not quite as easy as I implied in that message. The problem is the memory allocation. If a GMP function allocates some memory, we have to swizzle the pointer that comes back (where swizzle(p) { return p-sizeof(StgArrWords) }). Unfortunately you have to do this without giving the GC a chance to run, and there's no way to get this atomicity in plain Haskell+FFI, which is why the primops are still necessary. Perhaps one way to do it would be to define generic Integer primop wrappers - i.e. one wrapper for an mpz function that takes two arguments and returns one, etc. The primop implementations already work like this, except that the wrappers are CPP macros. If the wrapper were lifted to the level of a primop itself, then you could easily use different mpz functions by calling the appropriate primop passing the address of the mpz function. Cheers, Simon

2 1

RE: Network, sClose
by Bayley, Alistair 11 Aug '04

11 Aug '04

> -----Original Message----- > From: Glynn Clements [mailto:glynn.clements@virgin.net] > Sent: 10 August 2004 19:06 > To: Jon Fairbairn > Cc: glasgow-haskell-users(a)haskell.org > > > > * Shouldn't sClose be reexported from Network? > > Once you start down that route, you end up at the inevitable > conclusion that everything from the raw syscall imports > upwards needs to be re-exported. > > > * is there a general way to get ghci out of a state where > > it's got stuff open on inaccessible sockets? > > The solution to most problems with the Network module is not > to use the Network module, but to use Network.Socket instead. I had a similar (same?) problem while playing with networking, which was that you could open a socket and do stuff to it with just the functions from Network, but to properly close it you had to use Network.Socket.sClose. It also struck me as odd that Network exported all I needed to use sockets *except* sClose. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 2

Network, sClose
by Jon Fairbairn 10 Aug '04

10 Aug '04

I just got myself a copy of ghc-6.2.1 and was idly experimenting with Network in ghci. I tried Prelude System.Posix Network> do r <- recvFrom "localhost"$ PortNumber 9090; putStr r in one ghci and Prelude Network> do sendTo "localhost" (PortNumber 9090) "jellied eels\n" in another and was pleased to see jellied eels pop out of the first. Unfortunately a second attempt is not so happy: Prelude System.Posix Network> do r <- recvFrom "localhost"$ PortNumber 9090; putStr r *** Exception: bind: resource busy (Address already in use) According to the documentation there's some mention of "Address already in use" on this mailing list, but I couldn't find it -- I thought there used to be searchable archives of the mailing lists, but I couldn't find those either and resorted to google. A little experimentation revealed that: do sock <- listenOn$PortNumber 7607; (hdl,host,port)<- accept sock; s<-IO.hGetContents hdl; putStr$s; IO.hClose hdl; Network.Socket.sClose sock is nicely repeatable. The following questions arise: * Shouldn't recvFrom call sClose itself? * If not, how should one clean up after using recvFrom? * Shouldn't sClose be reexported from Network? * is there a general way to get ghci out of a state where it's got stuff open on inaccessible sockets? Jón -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

2 1

RE: GHCI/FFI/GMP/Me madness
by Simon Marlow 10 Aug '04

10 Aug '04

On 10 August 2004 13:03, MR K P SCHUPKE wrote: > Re GMP, Why not provide more GMP functions as primitives on the > Integer type, and avoid the need to call out to GMP via the FFI? Show us the code! :-p Cheers, Simon

2 1