October 2010 - Libraries

Changing the API of the network package to use ByteStrings instead of Strings
by Johan Tibell 31 Oct '10

31 Oct '10

Hi all, Now when network-bytestring is merged into network, the next natural step would be to slowly deprecate the String based functions for sending and receiving data in favor of the ByteString based ones. This will necessarily be a long process, as lots of code depend on these functions. Still I'd like to figure out a long term plan for completely removing the String based functions from the API, or at least deprecating them. In the long run I'd prefer not to have a separate ByteString API (under Network.Socket.ByteString) but to actually change the type of e.g. recv in Network.Socket. This would make the API smaller, making it easier to maintain and easier to understand. If that's not feasible, I'd at least like to add DEPRECATED pragmas to the String based functions to encourage the use of the ByteString based ones. I see two basic approaches: 1. Warn people of the upcoming change e.g. 6 months in advance, and then just change the types as part of a HP release. Delete the *.ByteString modules. 2. Deprecate the String based functions using pragmas, slowly move people over to the ByteString based ones. When everyone has moved over, change the types of the original functions to also use ByteStrings. Slowly migrate people back to the old functions (that now have a different type). Delete the *.ByteString modules. To be honest, I don't think 2 will ever work. From experience, without a deadline, people wont move. Is 1 even possible/desirable? What would a more concrete plan look like? Johan

4 3

2 issues and 1 proposal for runInUnboundThread
by Bas van Dijk 30 Oct '10

30 Oct '10

Hello, I found two small issues in Control.Concurrent: * Both runInBoundThread and runInUnboundThread use throw instead of throwIO. It's nicer to use throwIO in an IO context instead of throw because it guarantees ordering with respect to other IO actions. * runInUnboundThread explicitly checks the blocked status of the current thread which is redundant because mask also performs this check. I also have a new proposal: When you throw an asynchronous exception to a thread which is executing: `runInUnboundThread m`, m will keep executing and there's no way to kill it. I propose to catch asynchronous exceptions in runInUnboundThread and throw them to the thread which is executing m. m in turn can decide to catch or ignore them. In case m decides to ignore them or to rethrow them, the exception will be rethrown in the current thread: runInUnboundThread :: IO a -> IO a runInUnboundThread action = do bound <- isCurrentThreadBound if bound then do mv <- newEmptyMVar mask $ \restore -> do tid <- forkIO $ Exception.try (restore action) >>= putMVar mv let wait = takeMVar mv `Exception.catch` \(e :: SomeException) -> Exception.throwTo tid e >> wait wait >>= unsafeResult else action unsafeResult :: Either SomeException a -> IO a unsafeResult = either Exception.throwIO return The patch bundle attached to the ticket fixes the two issues and implements the above behavior. Discussion deadline: I don't think the fixes for the issues need discussion. They only need a review from one of the GHC devs. With regard to the proposal I propose a discussion deadline of 2 weeks from now: Thursday 28 October. Ticket: http://hackage.haskell.org/trac/ghc/ticket/4400 Regards, Bas

2 5

Proposal: Don't require users to use undefined
by Bas van Dijk 29 Oct '10

29 Oct '10

Dear all, Users of the sizeOf or alignment methods (:: a -> Int) of the Storable class are pushed to use 'undefined' in their programs. Take the following function from Foreign.Marshal.Alloc as an example: malloc :: Storable a => IO (Ptr a) malloc = doMalloc undefined where doMalloc :: Storable b => b -> IO (Ptr b) doMalloc dummy = mallocBytes (sizeOf dummy) I find the use of 'undefined' ugly; its only purpose is to help the type-checker by carrying around a type variable. It also makes the job of an optimizing compiler harder because, in order to avoid generating unnecessary code, the compiler needs to find out if undefined isn't used. More importantly however, 'undefined' is dangerous; The type-checker will never complain when you accidentally use 'undefined' in the wrong place increasing the change that your program will crash. Also, instance writers for the Storable class need to be careful not to evaluate the argument of sizeOf because it may be undefined. The use of 'undefined' is not only required by the Storable class. Users of the HasResolution class from Data.Fixed also need to use 'undefined' in order to get the resolution of a fixed value: class HasResolution a where resolution :: p a -> Integer I would like to propose solving this. My proposal consists of 3 sub-proposals: 1) Add module Data.Tagged. 2) Modify the sizeOf and alignment methods of the Storable class. 3) Modify the HasResolution class. What follows are more detailed explanations of the proposals: 1) Add module Data.Tagged. My proposal is to move the Data.Tagged module from Edward A. Kmett's tagged package to base. See: http://hackage.haskell.org/package/tagged The only modification that needs to be done is to drop the Default instance for Proxy because this will otherwise require that Data.Default be moved to base as well which isn't my intention. When this proposal is accepted Data.Default can provide the instance instead. 2) Modify the sizeOf and alignment methods of the Storable class. I would like to replace the following: class Storable a where sizeOf :: a -> Int alignment :: a -> Int with: class Storable a where sizeOf :: SizeOf a alignment :: Alignment a type SizeOf a = Tagged a Int type Alignment a = Tagged a Int To retrieve the actual size of type 'a' use: untag (sizeOf :: SizeOf a) where: untag :: Tagged s b -> b from Data.Tagged. See the following for the haddock documentation: http://code.haskell.org/~basvandijk/doc/ghc/html/libraries/base-4.3.0.0/For… Here's the definition of the previous malloc function to give you an impression how code looks when my proposals are accepted: malloc :: forall a. Storable a => IO (Ptr a) malloc = mallocBytes (untag (sizeOf :: SizeOf a)) (Note that this does require the ScopedTypeVariables language extension.) 3) Modify the HasResolution class. I would like to modify the HasResolution class in the same way. So replacing: class HasResolution a where resolution :: p a -> Integer with: class HasResolution a where resolution :: Resolution a type Resolution a = Tagged a Integer See the following for the haddock documentation: http://code.haskell.org/~basvandijk/doc/ghc/html/libraries/base-4.3.0.0/Dat… Note that Fixed also gets a HasResolution instance: instance HasResolution a => HasResolution (Fixed a) where resolution = retag (resolution :: Resolution a) where: retag :: Tagged s b -> Tagged t b from Data.Tagged. There's a possible 4th proposal that I'm thinking about: The Bits class from Data.Bits has the bitSize :: a -> Int method. Maybe it would be a good idea to replace that as well with: bitSize :: BitSize a; type BitSize a = Tagged a Int However I think bitSize is more often applied to an actual value than to 'undefined' so I need to investigate that a little further. A patch for the base package is attached to the ticket. I also attached patches for the ghc compiler, bytestring, binary, vector and dph. The latter are just some packages that were inside my ghc repository. This email is CCed to the maintainers of these packages. Deadline: 3 weeks from now (Tuesday 16 November 2010) but I will shift it when the discussion demands it. Ticket: http://hackage.haskell.org/trac/ghc/ticket/4443 Regards, Bas

18 37

Proposal: Merge network-bytestring into network
by Johan Tibell 28 Oct '10

28 Oct '10

Hi all, network-bytestring addresses two serious problems with the network package: performance and a semantically incorrect type for network data. Both problems are addressed by using ByteStrings instead of Strings in the types of e.g. recv and send. In addition, network-bytestring supports vectored I/O (also know as scatter/gather I/O) which yields better performance in many common use cases, such as HTTP servers. The merge doesn't break any old code: it introduces new APIs under Network.Socket.ByteString and Network.Socket.ByteString.Lazy but leaves the old API intact. The network-bytestring package is also better documented and tested that the network package. The API is portable. The network-bytestring package can be found at http://hackage.haskell.org/package/network-bytestring Discussion deadline: 2 weeks Johan

8 11

Re: Proposal: Don't require users to use undefined
by Axel Simon 27 Oct '10

27 Oct '10

On 27.10.2010, at 11:49, Henning Thielemann wrote: > Axel Simon wrote: > >> I do not see the problem that anybody is every going to >> accidentally evaluate sizeOf or alginment and get an unexpected >> "undefined" value back. I don't see the compiler optimization >> problem - it may exists but if the argument of Storage is fixed >> (and it always is in any use of Storage) then the compiler should >> be able to inline the 4 or 8 or whatever alignment evaluates to. > > I like to repeat my example here: > sizeOf (a,b) = sizeOf a + sizeOf b The point was that I assume that the usual use case is to marshal C structs where you would only use sizeOf in very specific patterns that do not include your example (or would you ever allocate memory to serialize two C structs, one after the other?). Axel

1 0

FW: Proposal: Require OverlappingInstances for the most specific instance only
by Simon Peyton-Jones 27 Oct '10

27 Oct '10

Libraries folk: see John's proposal below, which would affect libraries. John: I suggest a longer deadline, say end Nov. Unlike libraries, this one has global implications. Simon -----Original Message----- From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of John Smith Sent: 26 October 2010 20:42 To: glasgow-haskell-users(a)haskell.org Subject: Proposal: Require OverlappingInstances for the most specific instance only In the case of overlapping instance declarations, GHC currently requires the less specific instance to be compiled with OverlappingInstances for the more specific instance to be usable. This means that, for example, if you write type ChessBoard = Array (Int,Int) Piece there is no way to instance Show ChessBoard where show board = ... because Array is already an instance of Show, and was not compiled with OverlappingInstances. http://hackage.haskell.org/trac/ghc/ticket/3877 requests that OverlappingInstances be required for only the most specific instance declarations, as suggested in the documentation. "Perhaps the rule should instead say that the overlapping instance declaration should be compiled in this way, rather than the overlapped one ... We are interested to receive feedback on these points." SPJ offered to make this change, if the list users agree. (See comment 6.) Proposed deadline for discussion is 16th November. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

ANNOUNCE: iteratee-compress 0.1.1
by Maciej Piechotka 24 Oct '10

24 Oct '10

Iteratee-compress provides compressing and decompressing enumerators including flushing. Currently only gzip is provided but at least bzip is planned. Changes from previous version: - Independent from zlib library (Haskell one, not C) - Allow hand-flushing the contents (from outside). - Fix potential memory-leak Next goals: - BZip support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing? Regards PS. It did change API by removing dependency on zlib but I home such breakage in 0.1.x will be allowed

1 0

Proposal: Add Random instances for more base types
by Bas van Dijk 24 Oct '10

24 Oct '10

On Thu, Oct 7, 2010 at 2:27 PM, Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> wrote: > A lot of those can be removed if Random has instances for Word* by > default. Is there any reason they aren't already instances? On Thu, Oct 7, 2010 at 2:28 PM, Ian Lynagh <igloo(a)earth.li> wrote: > I see several instances for base types - the random package ought to > provide these. Proposal: Add Random instances for: * all the types in Data.Int: (Int is already provided) Int8, Int16, Int32, Int64 * all the types in Data.Word: Word, Word8, Word16, Word32, Word64 * almost all the types in Foreign.C.Types: CChar, CSChar, CUChar, CShort, CUShort, CInt, CUInt, CLong, CULong, CPtrdiff, CSize, CWchar, CSigAtomic, CLLong, CULLong, CIntPtr, CUIntPtr, CIntMax, CUIntMax, CFloat, CDouble Does it make sense to have Random instances for CClock and CTime? The patch is attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/4379 Deadline: 2 weeks (Friday 22 October 2010) Regards, Bas

5 6

Proposal: Faster toRational and fromRational
by Daniel Fischer 23 Oct '10

23 Oct '10

trac: http://hackage.haskell.org/trac/ghc/ticket/4344#comment:10 Proposal: include faster implementations for 1. toRational :: Float -> Rational 2. toRational :: Double -> Rational 3. fromRational :: Rational -> Float 4. fromRational :: Rational -> Double The semantics of these functions shall remain the same as it is now, only their speed will be affected. For fromRational, a fast integer logarithm is essential. Without access to the internal representation of Integer, it would be significantly slower, so this proposal includes the addition of modules defining the needed integer logarithm functions to the packages integer-gmp and integer-simple. Since Int is not available in the integer-* packages, those functions would return Int# values. I suggest adding wrappers integerLog2 :: Integer -> Int and integerLogBase :: Integer -> Integer -> Int to some module in base because those functions are far more generally useful. Currently integerLogBase is available from GHC.Float, so we might stick them there, although it's not very intuitive. Suggestions welcome. Discussion period: one week, until 29th October 2010 (I'd like to see it in 7.0). At http://hackage.haskell.org/trac/ghc/attachment/ticket/4344/FloatingRational… there's a bundle containing the proposed new implementations, QuickCheck tests and benchmarks. I get a pretty impressive speedup. Cheers, Daniel

7 9

xhtml: Unable to generate valid HTML with radio buttons
by Joachim Breitner 23 Oct '10

23 Oct '10

Hi, the xhtml function "radio", like any other form widged generating function, takes one parameter, which is used both for the name and for the id. For the radio buttons, one usually has multiple widgets with the same name. Having also the same id is invalid HTML. Of course this can be avoided by changing the id or not using the "radio" function. But I think it would be more sensible to change the behavior of the form widgets to _not_ add the id attribute by themselves. Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

2 2