April 2011 - Haskell-Cafe

Re: [Haskell-cafe] Re: Functional dependencies and Peano numbers (and hoogle-bug?)
by Oscar Finnsson 04 May '11

04 May '11

Thanks for the great feedback. The bijective example was especially interesting. While reading "Fun with Type Functions" I notices GNum as an interesting alternative to the Num type class but I couldn't find any such package on hackagedb. Do anyone know if there is anything like GNum on hackagedb? On an unrelated note: I hoogled "to" (i.e. http://haskell.org/hoogle/?hoogle=to) and just got a blank page. Nothing. Nil (not even <html>...</html>). Is this a bug or a "feature"? :) The reason I hoogled it was because I'm searching for something like explicit casting found in many other languages, something similar to > class To f t where > to :: f -> t > > instance To a a where > to x = x > > instance (Real a, Fractional b) => To a b where > to = realToFrac > > instance (Read a) => To String (Maybe a) where > to = maybeRead -- not from cgi :) so I can write something like > ("23.2" `to`) :: Maybe Double or > ((42 :: Integer) `to`) :: Float Anyone made a module/package that solves this problem already? I cannot be the first that needs generic type safe conversion... . -- Oscar

3 2

Binary and Serialize classes
by Evan Laforge 03 May '11

03 May '11

It's been remarked to me that relying on the Binary and Serialize classes is dangerous, because there's no guarantee they won't maintain a consistent format. So if my app uses the Serialize instances that come with cereal, it could suddenly fail to read old saves after an upgrade to cereal. However, neither binary nor cereal expose the underlying serialization algorithms for various types except through the instances, so I would have to copy and paste the code over if I want control over it. If I don't trust 'instance Serialize String' to not change behind my back, maybe I could at least trust 'Data.Serialize.stringToUtf8' to not change since if it did the name would now be wrong. Are these fears justified? I imagine if the Int instance for Serialize changed there would be an uproar and it would probably have to be changed back. I sent a bug to the maintainers of data-binary a long time ago about the Double instance not serializing -0, and they ignored it, probably because it would be bad to change the instance. So can I use the included instances without fear of them changing between releases? Of course I still run the risk of an instance from some other package changing, but I'm less likely to be using those. Speaking of that Double instance... both data-binary and cereal use decodeFloat and encodeFloat which mean they suffer from the same problems as realToFrac, namely that -0 becomes 0 and NaN becomes -Infinity (I'm not sure why the latter happens since the decoded values differ... must be a problem with encodeFloat). It's tempting to just get the ieee754 bitmap out and serialize that. I know I've seen this question around before, but is it possible to somehow cast a D# directly to bytes? I know I can write a C function and FFI that in, but it would be tidier to do it all in haskell. I guess I can probably use castPtr and memCpy, but I don't see the required addressOf. I.e. how would I write 'memcpy(buf, &d, sizeof(double));'?

6 7

versioning of Haskell packages
by Daniil Elovkov 03 May '11

03 May '11

Hello list I have an idea on versioning of Haskell packages and a small question about release model of Haskell Platform. Since the latter is shorter let's start with it. So, what is the release model of Haskell Platform? Is it released every N months and frozen at that point? Or some intermediate package/compiler updates can make the new version to appear out of schedule? Now, about package versioning. Haskell packages are flourishing and evolving at a high speed. Packages depend on other package and they evolve asynchronously. In result it is easy to end up in need of multiple versions of the same package in one program or maybe stumble upon other conflicts/problems. I'm expressing myself a little vaguely because I don't have a good example in my head right now. However, the idea is to maintain not just multi-digit version names that don't carry any semantics except that 1.1.3 is later than 1.1.2, but also somehow describe compatibility between versions. This way, even if the package A has jumped from 1.0 to 1.5 and the dependent package B has been stagnant all this time (and B depends on A 1.0), if we have information that 1.5 is compatible with 1.0, then we can safely use A 1.5 while building B. Or we could use whatever version of A is found in the system as long as its compatible with A 1.0 that B depends on. The compatibility relation can be made more fine grained and be applied not at the level of packages but that of modules, for example. This way, if we only use modules that are compatible with the version we depend on, it's fine to go with the newer version. Even if the package as a whole is not compatible. Also, when doing this at the level of modules, package authors could deliberately maintain compatibility by leaving the API of old modules intact and making them sort of wrappers to the new API which itself is not compatible with the older version. Of course, if the case when a newer version is backwards compatible is rare for most Haskell packages, then the idea doesn't make a lot of sense. But if it's common, then this could simplify building packages/programs and maintaining installed packages. What do you think? -- Daniil Elovkov

4 4

How to make ghc 7 with llvm?
by Magicloud Magiclouds 02 May '11

02 May '11

Hi, As I recalled, ghc started to support llvm from version 7. But there is a problem: there is no option to make ghc with llvm. So Library within ghc source will be in gcc's binary format. Then when I install other packages, they may complain that the binary format is not llvm, so they install some libraries again. Any way I could make ghc 7 with llvm? -- 竹密岂妨流水过山高哪阻野云飞

6 7

Posix IO & Unicode lookup exception
by Lee Pike 02 May '11

02 May '11

Hi, I wanted to see if anyone had an idea about why the following program results in an exception. The issue seems to be related to stdin to a POSIX file descriptors for a subprocess, and GHC's Unicode encoding lookup. I've tried to make the program as simple as possible to make the issue obvious. Consider: > module Pipe where > > import System.Process > import System.IO > import System.Posix.IO > > main = sequence_ $ replicate 100000 f > > f = do > (Just hin, _, _, prc) <- > createProcess (shell "./pipe_c.out") { std_in = CreatePipe > , std_out = UseHandle stdout > , std_err = UseHandle stderr} > > pin <- handleToFd hin > _ <- fdWrite pin ("h\n") > closeFd pin > waitForProcess prc and a trivial C program to read in the data (but doing nothing with it): --------------------------------------- #include <stdio.h> #define SIZE 10 int main(void) { char in[SIZE]; if(fgets(in, SIZE , stdin) != NULL); return 0; } ---------------------------------------- and executing > gcc -Wall -o pipe_c.out pipe_c.c > ghci Pipe.hs > main ... *** Exception: malloc: resource exhausted (out of memory) iconvOpen ("UTF-8","UTF-8"): resource exhausted (Cannot allocate memory) My best guess is that the GHC is calling iconv_open() <http://www.kernel.org/doc/man-pages/online/pages/man3/iconv_open.3.html>, but not making a subsequent call to iconv_close() <http://www.kernel.org/doc/man-pages/online/pages/man3/iconv_close.3.html>. (Actually, my best guess is I'm making a silly mistake, but I'm having trouble seeing it. :) ) I am running 2.6.35-28-generic (Ubuntu) and GHC 7.0.2, but I've observed the same issues with GHC 6.12.3. Lee

2 1

Wai and http-enumerator not as lazy as I'd like
by Erik de Castro Lopo 01 May '11

01 May '11

Hi all, I'm using Wai and http-enumerator to build a http proxy. The core of the code looks like this: import qualified Network.HTTP.Enumerator as HE import qualified Network.Wai as Wai serveRequest :: forall (m :: * -> *). (MonadControlIO m, Failure HE.HttpException m) => HE.Request m -> m Wai.Response serveRequest request = do HE.Response sc rh bs <- HE.withManager $ HE.httpLbsRedirect request return $ Wai.responseLBS (mkStatus sc) rh bs This works but does not run in constant space as I would have hoped. The thing is, HE.httpLbsRedirect returns a lazy ByteString and Wai.responseLBS writes a lazy ByteString, so why isn't the whole thing lazy? I'd appreciate any clues. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 4

GHC optimizer consuming memory
by mike frai 01 May '11

01 May '11

Hi, While using Michael Snoyman's persistent package, I discovered that a certain bit of code generated from it made the GHC optimizer consume a ridiculous amount of memory (ie. only when using the "-O" flag). I know very little about the GHC compiler and Michael Snoyman recommended I post my findings here to see what others thought. I've done what I can to extract the code generated from the persistent package and simplify/strip it down to the bare minimum of what's needed to cause this issue. You can find it in the attachment FromTest.hs. From my testing, removing five fields from Rec and the equivalent from the fromValue function - the memory consumption drops dramatically and I am able to compile. For your convenience, I've also attached FromTest.out, which is the output I get when compiling FromTest.hs using "ghc -O -v3". This is just the output up to the point it starts consuming a lot of memory. I've never seen anything after this point because my system slows down to a crawl (due to swapping) and I end up killing the process. Please let me know what you guys think or if you need any more information about this. Thanks, - Mike

2 1

How to keep cabal and ghci package versions in sync?
by Gracjan Polak 01 May '11

01 May '11

Hi all, I have a project with a .cabal file listing package dependencies using the usual version constraints ==X.Y.* <Z.W or >=K.J syntax. Standard route cabal configure; cabal build works correctly as it is able to select working set of package versions. I have also a .ghci file. When I run GHCi it uses all latest installed packages in the system. This prevents the project from loading. I tried to use 'cabal-dev ghci', but this still selects latest global packages. So, how to I load up ghci with the same package versions as selected by cabal? Thanks! -- Gracjan

5 7

Template Haskell support for GADTs
by Boris Lykah 01 May '11

01 May '11

Hi all! I am writing a library which allows to refer to the separate fields of a datatype. The fields are described as GADT with one constructor for each field. The constructors return GADT with the field type. The auxiliary data structures for this should be generated automatically via Template Haskell. I found that the GADTs produced by TH are not equivalent to the usual ones. They require additional extension -XTypeFamilies(for the equality constraints) along with -XGADTs, and, which is more important, are less type-safe. To describe the data structure I used ForallC as it was suggested in the closed ticket http://hackage.haskell.org/trac/ghc/ticket/3497 (Template Haskell support for GADTs) This is simplified code for data Sample = Sample {foo::String, bar::Int} written manually: data SampleField a where FooField :: SampleField String BarField :: SampleField Int and a GADT with similar structure generated via TH. $(do let gadt = mkName "THSampleField" let tv = mkName "a" let con1 = forallC [plainTV tv] (cxt $ [equalP (varT tv) (conT ''String)]) $ normalC (mkName "THFooField") [] let con2 = forallC [plainTV tv] (cxt $ [equalP (varT tv) (conT ''Int)]) $ normalC (mkName "THBarField") [] result <- dataD (cxt []) gadt [plainTV tv] [con1, con2] [] return [result] ) which produces data THSampleField a where THFooField :: a ~ String => THSampleField a THBarField :: a ~ Int => THSampleField a The expression asTypeOf FooField BarField fails to compile as expected because String cannot match Int, but asTypeOf THFooField THBarField is a valid expression of type (THSampleField a), which is very confusing and breaks the existing code. Am I missing something? If this is the only way to create the GADTs then I think we should consider reopening the ticket. -- Regards, Boris

1 0

More ideas for controlled mutation
by Edward Z. Yang 01 May '11

01 May '11

Laziness can be viewed as a form of controlled mutation, where we overwrite a thunk with its actual value, thus only running the code once and reaping great time benefits. I've been toying around with some ideas where we do alternative forms of controlled mutation. One such idea has to do with memoization. One way we memoize functions is by building up a data-structure that covers the entirety of input domain of the function, with the values in each slot being thunks for the corresponding function call. Now, this is all very nice and well, but for some types of inputs (like machine integers) we end up making a very big structure for a function for which, in practice, we'll only store and retrieve a few values of the domain. Hash tables take advantage of this fact by simply chaining together values in a linked list if they land in the same bucket. Could we have similarly bucketized memoization? What we want here is for a *thunk to possibly evaluate to different values, but calls to the API be observationally equivalent.* That is, if the only way I can inspect a dictionary list is do a lookup, I don't care if my representation is [(1,4),(2,2)] or [(2,2),(1,4)]. An obvious way to do this is to use unsafePerformIO to read out an IORef stating the value currently being looked up, and have the thunk evaluate to the pair of that key and the result. There are some synchronization concerns, of course: ideally we would only take out a lock on the thunk once we realize that the value doesn't already exist in the memotable, but I don't think there's a way in GHC Haskell to observe if a value is a thunk or not (maybe such a mechanism would be useful?) This seems related to lazy IO, where thunks are co-opted into performing input-output effects. After all, mutation is just a controlled form of IO. Is lazy IO evil or not? One consensus is that for operations that involve limited resources (file descriptors, etc.) lazy IO is too opaque for its own good. It seems we also haven't cracked it's performance problems either (for the relatively un-objectionable generation of an infinite stream of random numbers, Don Stewart notes: "There are real overheads here. Consider eagerly filling chunks and extracting elements piecewise."). But code that looks pure and can be reasoned about like pure code, but has the efficiency benefits of mutation is a very attractive thing indeed. I think it's worth some thought, though the programming world at large has a hard enough time reasoning about laziness even when everything is completely pure! Cheers, Edward P.S. An obvious question is whether or not we could use this technique to implement splay heaps or hash tables with pure interfaces. My opinion is no, because these structures demand you be able to *observe* the mutation.

4 5