- Haskell-Cafe - Haskell.org

Re: Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
by Mario Blažević 24 May '09

24 May '09

On Sat 23/05/09 2:51 PM , Duncan Coutts duncan.coutts(a)worc.ox.ac.uk sent: > On Sat, 2009-05-23 at 13:31 -0400, Mario Blažević wrote: > ... >> So the function is not strict, and I don't understand >> why GHC should evaluate the arguments before the call. > > Right, it's lazy in the first and strict in the second argument. As far > as I can see we have no evidence that is is evaluating anything before > the call. When I look at the Core definition of `test', it begins with \ (n1axl::integer:GHCziIntegerziInternals.Integer) (n2axn::integer:GHCziIntegerziInternals.Integer) -> %let as1sU :: integer:GHCziIntegerziInternals.Integer = base:DataziList.prod1 (main:Main.factors2 (base:DataziList.prod1 (base:GHCziNum.upzulist main:Main.lvl main:Main.lvl n1axl) base:DataziList.lvl1)) base:DataziList.lvl1 %in %case integer:GHCziIntegerziInternals.Integer (ghczmprim:GHCziPrim.parzh @ integer:GHCziIntegerziInternals.Integer as1sU) %of (dsapq::ghczmprim:GHCziPrim.Intzh) To my untrained eyes, this looks like it's evaluating > product $ factors $ product [1..n1]) which is the first argument to `parallelize'. I assume that %case in Core evaluates the argument to WHNF, just like case in Haskell. Then again, I could be completely misinterpreting what Core is, because I can't find any call to `parallelize' before or after that. It appears to be inlined in Core, regardless of whether the pragma > {-# INLINE parallelize #-} is there or not. Actually, I can't see any effect of that pragma in the core files whatsoever, but it certainly has effect on run time. >> Does anybody know of a pragma or another way to make a >> function *non-strict* even if it does always evaluate its argument? >> In other words, is there a way to selectively disable the strictness >> optimization? > > Yes, which is what pseq and par already do. > > If there's a bug, we need to reproduce it and report it. I cannot > reproduce it. If you mean that you can't reproduce anything that's contrary to the specification, that's not saying much: there are practically no guarantees on what `par' is supposed to accomplish. If you mean you can't reproduce anything you wouldn't expect, pray explain what is going on, because everybody else seems to be surprised. Or do you mean to say that *your* installation of GHC behaves the same when the function `parallelize' is defined in the same module and when it's imported?

1 0

ANN: hledger 0.5 released
by Simon Michael 24 May '09

24 May '09

I'm pleased to announce the hledger 0.5 release on hackage. hledger is a (mostly) text-mode double-entry accounting tool that generates precise activity and balance reports from a plain text journal file. It is a partial clone, in haskell, of John Wiegley's excellent ledger. hledger implements a subset of ledger's commands and options, and also provides some new ones. For basic use you can use hledger and ledger pretty much interchangeably on the same data files. For screenshots, live demo, docs etc. see http://hledger.org . Release notes are at http://hledger.org/NEWS , and below. To install: cabal install hledger [-fvty] [-fhapps]. I'd like to hear feedback, especially if you are having trouble getting started. Happy tracking! - Simon (sm on #ledger) 2009/05/23 hledger 0.5 released ------------------------------- Changes: * the vty flag is disabled by default again, to ease installation on windows * use ledger 3 terminology: a ledger contains transactions which contain postings * new "add" command prompts for transactions interactively and adds them to the ledger * new "convert" command transforms bank CSV exports to ledger format, with rule-based cleanup * new "histogram" command shows transaction counts per day or other reporting interval * most commands now work properly with UTF8-encoded text (Sergey Astanin) * invoking as "hours" is now less different: it just uses your timelog, not your ledger * --quarterly/-Q option summarises by quarter * --uncleared/-U option looks only at uncleared transactions * be more accurate about checking balanced amounts, don't rely on display precision * enforce balancing for bracketed virtual postings * fix bug in eliding of posting amounts * don't show trailing spaces on amountless postings * parse null input as an empty ledger * don't treat comments as part of transaction descriptions * require some postings in ledger transactions * require a non-empty description in ledger transactions * don't fail when matching an empty pattern, as in "not:" * make the web server handle the null path * code, api and documentation updates * add a contributor agreement/list Release contributors: * Simon Michael * Sergey Astanin Release stats: * Days since last release: 51 * Committers: 2 * Commits: 101 * Lines of non-test code: 2795 * Known errors: 0 * Tests: 76 * Performance: || hledger-0.4 | hledger-0.5 | ledger =========================++=============+=============+======= -f sample.ledger balance || 0.01 | 0.01 | 0.06 -f 1000.ledger balance || 1.33 | 1.46 | 0.53 -f 10000.ledger balance || 15.28 | 16.35 | 4.67

1 0

haddock could be a pretty-printer?
by Maurício 24 May '09

24 May '09

Hi, The new version of haddock makes use of GHC parser. How much of effort would take to make haddock generate pretty-print of the source code itself, including haddock documentation (although probably loosing other comments)? Maybe even an html version that documentation could point to? Thanks, Maurício

2 3

Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
by Mario Blažević 23 May '09

23 May '09

On Sat 23/05/09 4:15 PM , Alexander Dunlap alexander.dunlap(a)gmail.com sent: >>> Does anybody know of a pragma or another way to make a >>> function *non-strict* even if it does always evaluate its >>> argument? In other words, is there a way to >>> selectively disable the strictness optimization? >> >> parallelize a b | False = (undefined, undefined) >> | otherwise = a `par` (b `pseq` (a, b)) >> >> might do, unless strictness analysis is smart enough to >> know that the False guard is always, well, False. >> _______________________________________________ > > GHC.Prim.lazy? It's GHC.Exts.lazy nowadays, and it doesn't have any effect. Neither does the `| False' guard. The only way I found to disable the eager argument evaluation is to pass them in as functions: > parallelize :: Num t => (t -> a) -> (t -> b) -> (a, b) > parallelize a b = let a' = a 1 > b' = b 1 > in (a' `par` (b' `pseq` (a', b'))) Then it can be imported and called like this: > test n1 n2 = let (p1, p2) = parallelize > (\n0-> product $ factors $ product [n0..n1]) > (\n0-> product $ factors $ product [n0..n2]) This solution is incredibly fragile. If the declared type of parallelize is modified by replacing t by Integer, the evaluation becomes eager again. Also, the argument functions can't simply take () for argument which would make this solution reasonable. If this is all the strictness optimizer's fault, I'm awed by how difficult it is to trick it into not doing its job.

1 0

Pattern match question in HAXML code
by Max Cantor 23 May '09

23 May '09

Going through the instances for HTypeable (http://www.haskell.org/HaXml/HaXml/src/Text/XML/HaXml/TypeMapping.html#toHT… ) I saw the following instance for Either a b. My question is, why doesn't the pattern match in the where clause always fail? If (Left x) = m does not fail, doesn't that imply that m is a Left x and therefore the (Right y) = m should fail? thanks, max instance (HTypeable a, HTypeable b) => HTypeable (Either a b) where toHType m = Defined "Either" [hx, hy] [ Constr "Left" [hx] [hx] {-Nothing-} , Constr "Right" [hy] [hy] {-Nothing-}] where (Left x) = m (Right y) = m hx = toHType x hy = toHType y

2 1

Haskell Weekly News: Issue 119 - May 23, 2009
by Brent Yorgey 23 May '09

23 May '09

--------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090523 Issue 119 - May 23, 2009 --------------------------------------------------------------------------- Welcome to issue 119 of HWN, a newsletter covering developments in the [1]Haskell community. Announcements GHC porting works again. Ian Lynagh [2]announced that the [3]instructions for porting GHC to a new architecture now work again with the HEAD. If you get stuck when trying to do a port, feel free to ask on cvs-ghc at haskell.org or in #ghc on freenode. 6.10.4 plans. Ian Lynagh [4]announced plans for a 6.10.4 bugfix release of GHC. If you know of any bugs that you think should be looked into for 6.10.4, please let the development team know. The Timber compiler 1.0.3. Johan Nordlander [5]announced the release of version 1.0.3 of the Timber compiler. Timber is a modern language for building event-driven systems, based around the notion of reactive objects. It is also a purely functional language derived from Haskell, although with a strict evaluation semantics. 1.0.3 is a bug fix release, paving the way for future feature releases. mathlink-2.0.0.3. Tracy Wadleigh [6]announced the release of [7]mathlink, a library for writing Mathematica packages in Haskell. One simply writes some functions of type (MLGet a, MLPut b) => a -> IO b and provides a package specification in a simple DSL; the result is a program that exposes functions that can be called from Mathematica. text 0.2, fast and comprehensive Unicode support using stream fusion. Bryan O'Sullivan [8]announced the availability of [9]text 0.2, an efficient Unicode text library that uses stream fusion. New and notable in this release is support for lazy, chunked text, so you can process text files far larger than memory using a small footprint. Haskell Hackathon in Philadelphia. Brent Yorgey [10]announced Hac phi, a Haskell hackathon to be held in Philadelphia in July. Check out the [11]wiki page and add your name if you are interested in attending! More details to follow soon. feed2twitter 0.2 & hackage2twitter 0.2.1. Tom Lokhorst [12]announced the first release of [13]feed2twitter, a library for sending posts from a news feed to Twitter. EsotericBot 0.0.1. spoon [14]announced the release of [15]Esotericbot, a sophisticated, lightweight IRC bot, written in Haskell. atom 0.0.4. Tom Hawkins [16]announced a new release of [17]atom; this version adds an array datatype (A a). Hieroglyph-2.21 and buster, buster-gtk, and buster-network-2.0. Jeff Heard [18]announced new releases of [19]Hieroglyph, [20]buster, [21]buster-gtk, and [22]buster-network, with tons of changes; read Jeff's original announcement for details. TxtSushi 0.1. Keith Sheppard [23]announced the first version of [24]TxtSushi, a collection of command line utilities for processing tab-delimited and CSV files. It includes a utility for doing SQL SELECTs on flat files. Discussion Should exhaustiveness testing be on by default? Don Stewart started a [25]discussion, prompted by a [26]recent blog post, on whether coverage checking should be on by default, and other issues relating to compiler warnings and coding style. Proposal on the platform API policy question. Duncan Coutts [27]proposed a general policy for Haskell Platform release cycles and versioning, based on input from previous discussions. the problem of design by negation. Michael Mossey began a [28]discussion on software design philosophies. "Design by negation" considered harmful? Haskell in 3 Slides. John Van Enk [29]asked for ideas on a 3 to 4 slide introduction to Haskell. What do YOU think should be on those slides? Blog noise [30]Haskell news from the [31]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Bryan O'Sullivan: [32]Streaming Unicode support for Haskell: text 0.2. * Alex McLean: [33]Haskell hack. Music generation in Haskell. * Well-Typed.Com: [34]Building plugins as Haskell shared libs. A sneak preview of building Haskell shared libraries on Linux. * LHC Team: [35]New release: LHC 0.8. * Mark Wassell: [36]Grapefruit And Glade. * Conal Elliott: [37]The C language is purely functional. * >>> Will Donnelly: [38]Haskell: A Pretty Nice Language. * FP-Syd: [39]Sydney FP Group: FP-Syd #14.. * Dan Piponi (sigfpe): [40]Trace Diagrams with Monads. Quotes of the Week * roconnor: Damn it, I don't know how to make this as slow as python. * koeien: Let's register it [monomorphismrestriction.com] to prevent it from being used ;) * Elly: Rule 1 of malloc is the same as rule 1 of air travel: "Attempt at all costs to keep your number of landings equal to your number of takeoffs." * monochrom: I was trying to design a sensible language... then I downloaded ghc. * conal: The C ADT is implemented simply as String (or char *, for you type theorists, using a notation from Kleene) * Will Donnelly: monads are okay after a bit (though I'm still a little suspicious of them) About the Haskell Weekly News New editions are posted to [41]the Haskell mailing list as well as to [42]the Haskell Sequence and [43]Planet Haskell. [44]RSS is also available, and headlines appear on [45]haskell.org. To help create new editions of this newsletter, please see the information on [46]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [47]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/16984 3. http://hackage.haskell.org/trac/ghc/wiki/Building/Porting 4. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/16972 5. http://article.gmane.org/gmane.comp.lang.haskell.general/17200 6. http://article.gmane.org/gmane.comp.lang.haskell.general/17197 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mathlink 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58862 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58817 11. http://www.haskell.org/haskellwiki/Hac_%CF%86 12. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58801 13. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed2twitter 14. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58796 15. http://www.killersmurf.com/projects/esotericbot 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58752 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/atom 18. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58683 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Hieroglyph 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/buster 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/buster-gtk 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/buster%2Dnetwork 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58635 24. http://www.keithsheppard.name/txt-sushi 25. http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16926 26. http://ocaml.janestreet.com/?q=node/64 27. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11145 28. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/58784 29. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/58664 30. http://planet.haskell.org/ 31. http://haskell.org/haskellwiki/Blog_articles 32. http://www.serpentine.com/blog/2009/05/22/streaming-unicode-support-for-has… 33. http://yaxu.org/haskell-hack/ 34. http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/ 35. http://lhc-compiler.blogspot.com/2009/05/new-release-lhc-08.html 36. http://www.poundstone.org/blog/?p=231 37. http://conal.net/blog/posts/the-c-language-is-purely-functional/ 38. http://willdonnelly.wordpress.com/2009/05/19/haskell-a-pretty-nice-language/ 39. http://www.mega-nerd.com/erikd/Blog/FP-Syd/fp-syd-14.html 40. http://blog.sigfpe.com/2009/05/trace-diagrams-with-monads.html 41. http://www.haskell.org/mailman/listinfo/haskell 42. http://sequence.complete.org/ 43. http://planet.haskell.org/ 44. http://sequence.complete.org/node/feed 45. http://haskell.org/ 46. http://haskell.org/haskellwiki/HWN 47. http://code.haskell.org/~byorgey/code/hwn/

1 0

ICFP Participation
by Matthias Görgens 23 May '09

23 May '09

Hello, Please pardon my naive question: Is there a way to sign on for ICFP 09? The homepage (http://www.cs.nott.ac.uk/~gmh/icfp09.html) only seems to mention how to submit papers. Is there a way to attend as a mere participant? Thanks, Matthias.

3 4

Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...
by Mario Blažević 23 May '09

23 May '09

>>> You could probably see exactly what's happening in >>> more detail by going through the Core output. >> >> Thank you, this advice helped. The Core output indicates >> that function `test' evaluates the arguments to >> `parallelize' before it calls it. In other words, the >> call to `parallelize' is optimized as a strict function >> call -- which it is. The problem is that this >> optimization evaluates the arguments sequentially. >> Compiling with optimizations turned off regains the >> parallel execution. >> >> I guess I will report this as a GHC bug. Or is it a >> feature request? > > As Duncan suggessted, try with GHC head (grab a snapshot). `par` et al > are much improved. I already have, with the snapshot from 21st of April. It behaves the same as 6.8.2, except it runs for twice as long. I'd like to take back a part of what I said before, though: `parallelize' should be strict only in its second argument. Its strictness in the first argument should be the same as with `par`. Even though `parallelize x y' always evaluates both x and y, the following test works fine with optimizations even if `parallelize' is imported: main = putStrLn (snd $ parallelize undefined "Hello, World!") So the function is not strict, and I don't understand why GHC should evaluate the arguments before the call. Does anybody know of a pragma or another way to make a function *non-strict* even if it does always evaluate its argument? In other words, is there a way to selectively disable the strictness optimization?

3 2

Re: Extensible Exceptions and IO
by Alexander Dunlap 23 May '09

23 May '09

On Sat, May 23, 2009 at 9:09 AM, Ian Lynagh <igloo(a)earth.li> wrote: > On Sat, Apr 25, 2009 at 11:18:43AM -0700, Alexander Dunlap wrote: >> In the extensible exceptions paper[1], which I believe is the guide >> behind the current Control.Exception in GHC 6.10, a SomeIOException >> type is discussed so that it would be possible to use the nice >> interface for IOExceptions. Is this implemented anywhere? In the GHC >> libraries, all I see is the old interface just plugged into a simple >> wrapper, so you have to use guard . isDoesNotExistError (for example) >> with catchJust to catch a certain type of exception. If not, are there >> any plans to implement it? > > I'm not aware of anyone currently working on putting the various core > libs' exceptions into a sensible hierarchy, but it would be great if > someone was to do so! > > I'd suggest that the best way to do this would be initially a > combination of discussions on the mailing list (if anything is > non-obvious) and building a design (and, if appropriate, rationale) on a > wiki page, and ending with a library submissions proposal once you have > a design worked out: > > http://www.haskell.org/haskellwiki/Library_submissions > > > Thanks > Ian > > I'm moving this from the GHC users' mailing list to the haskell-cafe mailing list because I think the discussion probably involves the entire Haskell community. Hi all, We have this new exception hierarchy in GHC base-4 and a lot of new machinery for dealing with it. Other libraries also seem to be springing up to provide alternative methods of dealing with these new exceptions. However, I have found that in most of my programming, the new exception functionality cannot be used to its fullest extent because the exceptions in the core libraries are not part of any sensible "tree" of exceptions, even though having this giant exception tree seems to be one of the premises of the new exception library. For example, there is an ArithException type in Control.Exception which records various arithmetic exceptions. However, there are two problems: (1) in order to fit in with the extensible exceptions theme, the type ought to be called SomeArithException and all of the types of ArithExceptions ought to be sub-exceptions of it, and (2) to my knowledge, this exception type doesn't seem to be thrown by anything in the base libraries. I think the biggest culprit is the IOException type, which also happens to be probably the most commonly-used exception type, since exceptions from IOException cannot really be anticipated and prevented. The current design of IOException is as follows. There is an abstract type called IOException. This can be queried with functions like isDoesNotExistError (which determines if the exception is because a file did not exist). Furthermore, to make an IOException, one has to use the mkIOError function, which takes a value of type IOErrorType, which is again an abstract type. I believe the reason for the abstract types is to allow implementations to extend the range of exceptions. Unfortunately, this has even more problems. For example, the error returned by using readFile on a directory cannot be determined using any Haskell98 function, meaning that code that wants to detect this error cannot be portable to compilers that don't have the new InappropriateType IO exception. The biggest problem with the current design of IOException, however, is that it doesn't play very nicely with the main hierarchy. Like with ArithExceptions, there should be a SomeIOException type. http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf, which was the original paper on extensible exceptions, recommends having a class for IOExceptions that would allow us to get standard information from any specific IOException. I asked the GHC-users mailing list about this and Ian Lynagh recommended starting a discussion about how to put all of the core library exceptions into a sensible hierarchy. I think the goals here ought to be to make our new hierarchy as backward-compatible as possible. In particular, since many programs rely on the isWhateverError functionality, it would be nice to keep these in place. For IOExceptions, I think it would be nice to have a more multi-layered hierarchy than just SomeIOException and its subtypes. For example, I could see a hierarchy for IOExceptions looking something like this: SomeIOException - SomeCouldNotOpenException - AlreadyExists, NoSuchThing, PermissionDenied, InappropriateType - SomeResourceException - ResourceBusy, ResourceExhausted, ResourceVanished etc. I'm not all that familiar with the various exceptions and how they are used, so I'm not really able to propose a complete hierarchy for all the exceptions. I guess the purpose of this email was just to start off a discussion about what our exception hierarchy ought to look like. Thanks for reading this (admittedly long) message. Alex

1 0

Data.Binary suboptimal instance
by Andrew Coppin 23 May '09

23 May '09

So lately I've been working on a little program to generate trippy graphics. (Indeed, some of you may remember it from a few years back...) Anyway, getting to the point, I just restructured my program. As part of the restructuring, I got rid of all the jiggery-pokery with Data.Array.Storable and so forth and decided to use Data.Binary. My first problem was quite simple. I want to write a program that reads an item from the input file, processes it, writes it to the output file, and repeats until the input file is empty. Data.Binary doesn't appear to provide any obvious way to do this. You can't be in the Get and Put monads simultaneously, and I can't figure out how to interleave them. In the end, I ended up with something like xs <- decodeFile f1 encodeFile f2 (map f xs) Unfortunately, it looks like this doesn't do what I want. Serialised lists have their length prepended to them, which means that encodeFile is going to have to generate the *entire* list in memory so it can count how big it is, before it can output a single byte to disk. (!) This is particularly annoying since the output list will be exactly the same size as the input one, and the very first thing decodeFile is doing is reading in that size figure. Maybe there's a way around this glitch, and I just haven't thought of it yet. But you'd think that wanting to lazily process data from an input file and write it into an output file would be an extremely common use-case. Given that, I'm not seeing an obvious way to handle it. Anyway, that's one small problem, but I can live with it. There's another, much bigger problem though, and that's really what I wanted to talk about... As we all know, Data.Binary is *built* for speed. So imagine my shock when my newly adjusted program now based around this library turned out to be massively slower, and the files it produced were drastically larger. It didn't take me that long to dig up the problem. The problem seems to boil down to this: The Binary instance for Double (and Float, by the way) is... well I guess you could argue it's very portable, but efficient it isn't. As we all know, an IEEE-754 double-precision floating-point number occupies 64 bits; 1 sign bit, 11 exponent bits, and 52 mantissa bits (implicitly 53). I had assumed that the Binary instance for Double would simply write these bits to disk, requiring approximately 0 computational power, and exactly 64 bits of disk space. I was wrong. ...what it *actually* does is convert the 64-bit Double into a 32-bit exponent and an arbitrary-precision integer part. (!) It appears to do this by floating-point arithmetic rather than just low-level bit shuffling. Looking up how arbitrary-precision integers are serialised, I see that there's an 8-bit "flag" indicating whether the integer fits into 32 bits, and if it doesn't, there's an 8-bit sign value, followed by a serialised list of bytes. So, in other words, a 32-bit length value, followed by the bytes themselves. To summarise, when I ask for a 64-bit Double to be serialised, I get this: 32-bit exponent. 8-bit flag (probably always "1") 8-bit sign (either "0" or "1") 32-bit size (probably always "8") 64-bit mantissa That's 144 bits in total, i.e., 225% larger than the original Double. (Let's not even go into how much computer power it takes to construct all this data before it's written to disk...) So, that's why my files balooned in size, and why my program slowed to a crawl. But how do I fix this? Well, my solution was simple, brutal, and probably *highly* non-portable. It begins with Unsafe.Coerce (that's never a good thing!) Put simply, if you take your 64-bit Double and unsafeCoerce it into a Word64 and then ask Data.Binary to serialise that, it writes it straight to disk without screwing around with it first. The result ought to be portable to any architecture that uses IEEE-754 arithmetic natively. (Anybody know of an arch this *doesn't* apply to?) But sure, if you wanted to do this on some other architecture with a different native float format, you'd have to write some trixy code to handle it. (And then add conditional compilation for it.) Is there any danger that there might be some kind of improvement to the Double instance in the next version of Data.Binary? END.

3 6