December 2010 - Haskell-Cafe

windows network programming
by Michael Litchard 22 Jan '11

22 Jan '11

I took a quick look on hackage for an interface to windows networking function calls, and didn't find anything that worked. I may have overlooked something. What's the state of windows network programming? Any recommendations for a good package?

6 10

parsec2 vs. parsec3... again
by Evan Laforge 20 Jan '11

20 Jan '11

Yeah, I know this has been discussed a number of times, but I have some concrete questions I haven't seen asked before. And the "parsec 3 is now as fast as parsec 2" thing I've seen around doesn't seem to be true for me. I have an app that does a lot of parsing of small expressions. It's currently parsec2 operating on lots of little Texts (after an unpack, of course). A few parsing functions show up near the top of the profile output, so I thought an obvious improvement would be to parse Text directly and avoid the overhead and garbage of unpacking. Since parsec3 is now supposed to be as fast as parsec2 I thought I would give it a try. Parsec3 is 3.1.0, parsec 2 is 2.1.0.1: parsec2, String: total time = 10.66 secs (533 ticks @ 20 ms) total alloc = 2,340,113,404 bytes (excludes profiling overheads) parsec3, String: (this is just after upgrading the library and editing it to fix breakage from Parser being a type alias now) total time = 13.76 secs (688 ticks @ 20 ms) total alloc = 2,706,625,256 bytes (excludes profiling overheads) parsec3, Text: (wrote a Text instance similar to the one for ByteString, updated imports, no longer unpacking to String) total time = 15.96 secs (798 ticks @ 20 ms) total alloc = 3,338,005,896 bytes (excludes profiling overheads) This is not very encouraging! Especially strange is how Text generates *more* allocation... I'd expect less since it doesn't unpack all the Texts. The parsing functions are no longer at the top of the profile, but there are new 'unParser' and 'parsecMap' and 'parserBind' up at or near the top. 'unParser' just looks like it's unwrapping the Parsec newtype, so I don't fully understand how it's the most expensive, but it's called on every bind so it does get called a lot. There are no obvious super expensive ones, just lots and lots of them that add up. Parsec 3's unParser covers up the parsing function I wrote, so it's now hard to tell what the expensive parsing function actually is. I've seen a few remarks that you can't just throw together parsers and expect them to be fast, you have to profile them, but nothing on how to actually interpret the results of profiling. For instance, here's one of the main expensive parsers: p_unsigned_float :: P.CharParser st Double p_unsigned_float = do i <- P.many P.digit f <- P.option "" (P.char '.' >> P.many1 P.digit) if (null i && null f) then P.pzero else do let int = List.foldl' (\total c -> 10 * total + fromIntegral (Char.digitToInt c)) 0 i frac = foldr (\c total -> (total + fromIntegral (Char.digitToInt c)) / 10) 0 f return (int + frac) There's an obvious problem where I get the digits as a String and then parse that with list functions, but I can't see any way to get parsec to return a chunk of Text. This is roughly how parsec itself parses numbers, in Text.Parsec.Token. So, my current options are either figure out some way to speed up parsec3+Text, revert to parsec2+String and give up, or try an entirely different parsing library. I've heard attoparsec is fast but I'd have to switch to utf8 bytestring which is a big change, and Text seems like the more correct choice anyway. Any ideas or experience?

7 14

Template Haskell a Permanent solution?
by Jonathan Geddes 18 Jan '11

18 Jan '11

Cafe, First let me say that Template Haskell is very powerful and a lot of great work has been done in this area. It fills in a number of holes in Haskell's feature set. But TH gives me the same feeling as other language features that have been described as "bolted on." Also, TH is both library and built-in syntax (via an extension) which feels strange to me. Finally, It's very complicated to do some simple things. I see TH used most for the following tasks: #1 Parse a string at compile-time so that a custom syntax for representing data can be used. At the extreme, this "data" might even be an EDSL. #2 Provide instances automatically. I would propose that more specialized features be implemented to accomplish these tasks. To start, I'll throw out some ideas that provide these capabilities. For TH use #1, compile-time parsing of arbitrary strings, I think it would be nice for quasiquote semantics to be modified so that code like > json :: String -> JsonObject > json = ... > > data = [ json | > { "name" : "Jonathan" > , "favorite language": "Haskell" > } >|] causes the function json to be called at compile time with a string argument of " {\"name\" : \"Jonathan\"\n , \"favorite language\": \"Haskell\"\n }". The whole expression being then replaced with the result of the function application. What I like about this is that defining "quasiquoters" is trivial. They're just functions of the form String -> a. Many such quasiquoters already exist and would be ready for use! I imagine certain rules would apply, ie a quasiquoter must be defined prior to use and in a separate module, etc. For TH use #2, automatic instances, I would propose a way of declaring that a class can be automatically derived, and therefore added to the set [Eq, Ord, Show, Read, ... , etc]. This is the set of classes that can be put in the "deriving" clause of a type declaration. I don't know exactly what the syntax for this would look like, but I imagine it would look a bit like the various current implementations of automatic instances in TH. Again, TH is very powerful, and fills in a number of holes in Haskell's feature set. But it leaves me wondering if these holes should not be filled in by other, more specialized features, leaving TH to continue to find other holes to fill. I'm wondering if others see TH as a permanent solution, or if you agree with me that some of TH's most common usages should have more specialized features dedicated to them. It may very well be that I am simply not experienced enough with TH to fully appreciate and embrace it. By the way, did I miss any uses of TH as common as the ones I mentioned? --Jonathan

9 16

Misleading MVar documentation
by Edward Z. Yang 16 Jan '11

16 Jan '11

Merry Christmas all! Is it just me, or does the Control.Concurrent.MVar documentation seem a bit misleading? In particular, we should explicitly note the race conditions for not just swapMVar but also readMVar, withMVar, modifyMVar_ and modifyMVar, and clarify that the safety guarantees of the latter three pertain to their handling of asynchronous exceptions. It might also be good to tell people that if they need race-free operations of this style, STM is a good alternative to look at, even if only one variable is being synchronized over. Cheers, Edward

9 14

Haskell for Gingerbread
by Chris Kuklewicz 13 Jan '11

13 Jan '11

Hi folks, I have been looking at developing for my Android phone which is running Gingerbread (Android version 2.3). The important thing about the official development kit is this: The new native development kit (C/C++ cross compiler for ARM) is that the you can create android applications from pure C without using the Dalvik/Java virtual machine at all. The thinking behind this was probably for game developers to be able to avoid their VM. So all that might be needed is a Haskell compiler with a C-backend that emits ARM-compatible code and an initially minimal android runtime. Implementing to the new "native_activity.h" allow for the usual application life-cycle: onStart, onPause, onResume, onStop... Some options I have not had a chance to look into: 1) GHC arm port and -via-C 2) jhc (and lhc) generated C 3) port nhc98 4) port yhc bytecode runtime Does anyone know who else is thinking along any of these lines? Are there 5th or 6th routes to take? Cheers, Chris Kuklewicz

5 5

Unknown symbol `__dso_handle' with Template Haskell and wxHaskell
by Alexander Bau 07 Jan '11

07 Jan '11

Hi, I am using Template Haskell and wxHaskell [1]. When Graphics.UI.WX is loaded during THs code generation, I get the following error: > ... > Loading package wxdirect-0.12.1.3 ... linking ... done. > ghc: /usr/local/lib/wxcore-0.12.1.6/ghc-6.12.3/HSwxcore-0.12.1.6.o: > unknown symbol `__dso_handle' > Loading package wxcore-0.12.1.6 ... > linking ... ghc: unable to load package `wxcore-0.12.1.6' System stats: ghc-6.12.3 template-haskell-2.4.0.1 wx-0.12.1.6 Regards, Alex [1] Example: -- Test.hs ---------------------- {-# LANGUAGE TemplateHaskell #-} module Test2 where import Language.Haskell.TH import qualified Graphics.UI.WX as WX foo :: Q [Dec] foo = do info <- reify ''WX.Color runIO $ print info return [] -- Main.hs ---------------------- {-# LANGUAGE TemplateHaskell #-} module Main where import Test $(foo)

3 3

implementing RealFloat decodeFloat
by Claude Heiland-Allen 06 Jan '11

06 Jan '11

Hi everyone, I've been working on [0] Haskell bindings for [1] libqd for [2] double-double and quad-double arithmetic, and have been struggling to implement [3] RealFloat, in particular [4] decodeFloat, mostly because of its postcondition but also some issues relating to variable precision: ---8<--- If decodeFloat x yields (m,n), then x is equal in value to m*b^^n, where b is the floating-point radix, and furthermore, either m and n are both zero or else b^(d-1) <= m < b^d, where d is the value of floatDigits x. In particular, decodeFloat 0 = (0,0). ---8<--- (BTW: that should probably really be "... <= abs m < ..."; perhaps this code could be added to the report and/or documentation, if it is correct: validDecode :: RealFloat f => f -> Bool validDecode f = case decodeFloat f of (0,0) -> True (m, e) -> b^(d-1) <= abs m && abs m < b^d where b = floatRadix f d = floatDigits f ) The double-double and quad-double types do not have a fixed precision, though they do have a fixed minimum precision: this means that decodeFloat will (in general) lose some precision. This is because for example in: data DoubleDouble = DoubleDouble !CDouble !CDouble dd = DoubleDouble a b the semantics are that "dd = a + b", with |a|>>|b|; coupled with the IEEE implicit leading 1 bit, this means that there may be large gaps between exponents: for example: "1 + 0.5**100 :: DoubleDouble". So far I've got a "mostly working" implementation thus: decodeFloat !(DoubleDouble a b) = case (decodeFloat a, decodeFloat b) of ((0, 0), (0, 0)) -> (0, 0) ((0, 0), (m, e)) -> (m `shiftL` f, e - f) ((m, e), (0, 0)) -> (m `shiftL` f, e - f) ((m1, e1), (m2, e2)) -> let fixup m e = if m < mMin then fixup (m `shiftL` 1) (e - 1) else if m >= mMax then fixup (m `shiftR` 1) (e + 1) else (m, e) mMin = 1 `shiftL` (ff - 1) mMax = 1 `shiftL` ff ff = floatDigits (0 :: DoubleDouble) g = e1 - e2 - f in fixup ((m1 `shiftL` f) + (m2 `shiftR` g)) (e1 - f) where f = floatDigits (0 :: CDouble) This does meet the postcondition as specified (which leads to breakage in other RealFloat methods), but has a recursion with no termination proof (so far), and is lossy in general: > let check f = uncurry encodeFloat (decodeFloat f) == f > check (1 + 0.5 ** 120 :: DoubleDouble) False It does however seem to meet a weaker condition: > let check2 f = (decodeFloat . (`asTypeOf` f) . uncurry encodeFloat . decodeFloat $ f) == decodeFloat f > check2 (1 + 0.5 ** 120 :: DoubleDouble) True Questions: 1. Is this weaker condition likely to be good enough in practice? 2. Can my implementation of decodeFloat be simplified? Thanks for any insights, Claude [0] http://hackage.haskell.org/package/qd [1] http://crd.lbl.gov/~dhbailey/mpdist/ [2] http://crd.lbl.gov/~dhbailey/dhbpapers/arith15.pdf [3] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.ht… [4] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.ht… -- http://claudiusmaximus.goto10.org

2 1

Polymorphic function over pairs of maybes.
by Edward Amsden 06 Jan '11

06 Jan '11

Hello all: I'd like to right a function that could take a structure with type (random example): (Int, (String, (Int, Int))) and another where each individual value is a Maybe of the corresponding type, for example: (Maybe Int, (Maybe String, (Maybe Int, Maybe Int))) and perform a fromMaybe using the values to produce a new value with the original types. The catch is, I'd like to be able to do that for an n-deep structure with any type, without having to write a separate function for them. I'm not even sure that this is possible, but perhaps someone could explain how it is or isn't? -- Edward Amsden Undergraduate Computer Science Rochester Institute of Technology www.edwardamsden.com

7 8

thread safety, IO arrays, and IO refs
by Eric Stansifer 05 Jan '11

05 Jan '11

Hello, I wish to use a mutable array in multiple threads. Can IO arrays be used in any thread, or only the thread they are created in? (So if I create an IO array in one thread, pass it to another via an MVar, can I read / edit it in that other thread?) Similarly about IORefs... can they be used across threads? (Obviously I will need to manage locking myself if I use an IO ref or array.) Are there any good resources on concurrency in Haskell that would answer questions similar to these? I've been learning by reading the ghc library documentation, but of course it's not comprehensive. The online tutorials I've seen aren't so in-depth, either. Thanks, Eric

4 4

What's the motivation for η rules?
by David Sankel 04 Jan '11

04 Jan '11

TIA, David -- David Sankel Sankel Software www.sankelsoftware.com

6 6