September 2010 - Haskell-Cafe

Uniting graphics libraries
by Tillmann Vogt 18 Sep '10

18 Sep '10

Hi, I have nearly finished writing a Collada-output library to make 3d animation files. Before doing this I have looked at two libraries on hackage that parse Collada to display it. For my library I have copied the types from gpipe-collada and extended them. Now I am thinking that it would be nice if all 3d libraries would use the same data type. Currently gpipe-collada, graphics-formats-collada, obj, ... parse 3d-formats. FieldTrip, lambdacube-engine, ... (to mention examples) can generate and/or display 3d-objects. But they all cannot be combined without tedious type conversions. The obvious argument is that every application has its own needs. This is of course true but I think that the Collada format shows how to deal with this (you can do quite a lot with profile_common). I would be willing to write patches for some libraries and make a discussable 3d-types library based on Collada. Hope you agree, Tillmann

2 4

Curious why "cabal upgrade parsec" not installing latest version
by Peter Schmitz 17 Sep '10

17 Sep '10

Not that I'm having any problem with parsec 2.1.0.1, but I guess I would like to install the latest (3.1.0), unless there is a reason not to. I can't seem to get Cabal to do so; thanks in advance for any help. I don't understand part of the output from "cabal install --dry-run --reinstall -v parsec" at the end below, which includes: "selecting parsec-2.1.0.1 (hackage) and discarding parsec-2.0, 2.1.0.0, 3.0.0, 3.0.1 and 3.1.0". (http://hackage.haskell.org/package/parsec seems to point to 3.1.0.) Under Windows XP: > H:\proc\dev\cmd>cabal update > Downloading the latest package list from hackage.haskell.org > > H:\proc\dev\cmd>cabal info parsec > * parsec (library) > Synopsis: Monadic parser combinators > Latest version available: 3.1.0 > Latest version installed: 2.1.0.1 > Homepage: http://www.cs.uu.nl/~daan/parsec.html > Bug reports: [ Not specified ] > Description: Parsec is designed from scratch as an industrial-strength > parser library. It is simple, safe, well documented (on the > package homepage), has extensive libraries and good error > messages, and is also fast. It is defined as a monad > transformer that can be stacked on arbitrary monads, and it > is also parametric in the input stream type. > Category: Parsing > License: BSD3 > Author: Daan Leijen <daan(a)microsoft.com>, Paolo Martini <paolo(a)nemail.it> > Maintainer: Derek Elkins <derek.a.elkins(a)gmail.com> > Source repo: [ Not specified ] > Flags: base4 > Dependencies: mtl -any, bytestring -any, base >=4 && <5, syb -any, > base >=3.0.3 && <4 > Documentation: [ Not installed ] > Cached: No > Modules: > Text.ParserCombinators.Parsec > Text.ParserCombinators.Parsec.Char > Text.ParserCombinators.Parsec.Combinator > Text.ParserCombinators.Parsec.Error > Text.ParserCombinators.Parsec.Expr > Text.ParserCombinators.Parsec.Language > Text.ParserCombinators.Parsec.Perm > Text.ParserCombinators.Parsec.Pos > Text.ParserCombinators.Parsec.Prim > Text.ParserCombinators.Parsec.Token > > > H:\proc\dev\cmd>cabal upgrade parsec > Resolving dependencies... > No packages to be installed. All the requested packages are already installed. > If you want to reinstall anyway then use the --reinstall flag. > > > H:\proc\dev\cmd>cabal install --dry-run --reinstall parsec > Resolving dependencies... > In order, the following would be installed (use -v for more details): > parsec-2.1.0.1 > > > H:\proc\dev\cmd>cabal install --dry-run --reinstall -v parsec > H:\proc\tools\Haskell Platform\2010.1.0.0\bin\ghc.exe --numeric-version > looking for package tool: ghc-pkg near compiler in > H:\proc\tools\Haskell Platform\2010.1.0.0\bin > found package tool in > H:\proc\tools\Haskell Platform\2010.1.0.0\bin\ghc-pkg.exe > H:\proc\tools\Haskell Platform\2010.1.0.0\bin\ghc-pkg.exe --version > H:\proc\tools\Haskell Platform\2010.1.0.0\bin\ghc.exe --supported-languages > Reading installed packages... > H:\proc\tools\Haskell Platform\2010.1.0.0\bin\ghc-pkg.exe dump --global > H:\proc\tools\Haskell Platform\2010.1.0.0\bin\ghc-pkg.exe dump --user > Reading available packages... > Resolving dependencies... > selecting parsec-2.1.0.1 (hackage) and discarding parsec-2.0, > 2.1.0.0, 3.0.0, 3.0.1 and 3.1.0 > selecting base-3.0.3.2 (installed) and 4.2.0.0 (installed) and discarding > syb-0.1.0.0, 0.1.0.1, 0.1.0.2, 0.1.0.3, 0.2 and 0.2.1 > selecting ffi-1.0 (installed) > selecting ghc-prim-0.2.0.0 (installed) > selecting integer-gmp-0.2.0.0 (installed) > selecting rts-1.0 (installed) > selecting syb-0.1.0.2 (installed) > In order, the following would be installed: > parsec-2.1.0.1 (reinstall) changes: base-4.2.0.0 -> 3.0.3.2 > > H:\proc\dev\cmd> --

7 15

types for parsing a tree
by Jared Jennings 17 Sep '10

17 Sep '10

Dear haskell-cafe: I'm trying to parse an Open Financial eXchange (OFX) 1.x file. It details my bank transactions, like debit card purchases. It's SGML-based and it goes like: <OFX>[...] <STMTRS>[...] <STMTTRN>[...] <TRNUID>9223ry29r389 <NAME>THE GROCERY STORE BLABLABLA <TRNAMT>234.99 </STMTTRN> <STMTTRN>[...] <TRNUID>1237tg832t <NAME>SOME DUDE ON PAYPAL 4781487 <TRNAMT>2174.27 </STMTTRN> </STMTRS> </OFX> I've left out a bunch, but as you can see it's tree-shaped, and the only reason they didn't misuse XML as a data serialization language instead of SGML was because it wasn't popular yet. (OFX 2.x uses XML but my bank doesn't use OFX 2.x.) When I imagine how to put this into a data structure, I think: -- The '...' below is stuff like the date, info about the bank data OFX = OFX { statement :: StatementResponse, ... } -- The '...' below is stuff like the account number data StatementResponse = StatementResponse { transactions: [Transaction], ... } data Transaction = Transaction { id :: String, name :: String, amount :: Decimal, sic :: Maybe Int, ... } Then I tried to make a parser to emit those data types and failed. I come from Python, where there's no problem if a function returns different types of values depending on its inputs, but that doesn't fly in Haskell. I've tried data OFXThing = OFX { statement :: OFXThing } | StatementResponse { ... transactions :: [OFXThing] } but that would let me make trees of things that make no sense in OFX, like a transaction containing a statement. I made a data Tree k v = Branch k [Tree k v] | Leaf k v type TextTree = Tree String String and a tagsoup-parsec parser that returns Branches for tags like OFX, and Leafs for tags like TRNUID. But now I just have a tree of strings. That holds no useful type information. I want my types to say that OFXes contain statements and statements contain transactions - just like the OFX DTD says. How can I construct the types so that they are tight enough to be meaningful and loose enough that it's possible to write functions that emit them?

4 5

Stateful DSLs
by Günther Schmidt 17 Sep '10

17 Sep '10

Hello, I'd want to create a EDSL where I want to be able to statically ensure that expressions can only be built according to a particular "state". Like in a network application, SMTP client for example, where I can only issue commands if the application is in a certain state. Are there any Haskell examples for this sort of thing? Günther

3 3

A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
by Paolo Giarrusso 17 Sep '10

17 Sep '10

Hi, after Andrew Coppin's odissey [1], I also had a few problem with cabal, which stopped installing new packages. Details will follow; meanwhile, here are some questions prompted by what happened: - when recompiling a package with ABI changes, does cabal always update dependent packages? It seems "not always" - it didn't update itself, nor refuse the breaking upgrade, and the ABI breakage caused linker errors on Setup.hs. Luckily, cabal was already linked so I could always use it for queries. - can cabal extract and check dependencies as specified in the .hi files? I had a broken dependency which I could see with "grep" but not otherwise. - is there a "specification" of which are the "core" packages? Not sure if this is more useful as a bug report or as discussion, or if I just misused cabal and it's the only perfect software in the world; still I wanted to share my experience. Also I am not sure if this is the best place - but I'm not subscribed to other lists, and the previous "cabal odissey" was posted here, so I hope it's fine. A related idea is that Gentoo had a tool which not only extracted such dependencies, but recompiled all affected packages. While package removal is not supported through cabal, it is sometimes needed (and well, it should be supported at some point). See for instance this FAQ: http://www.haskell.org/cabal/FAQ.html#dependencies-conflict My problem seems a nastier variation of the one described there :-(. Details follow. Best regards [1] http://groups.google.com/group/haskell-cafe/browse_thread/thread/787c67b31f… -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/

11 23

IO-oriented cache library for interacting with GUI
by Alexey Karakulov 17 Sep '10

17 Sep '10

Hi. I'm writing GUI (gtk) program which purpose is take some data as user input, perform some evaluations, and produce some plots and coefficients. Since some evaluations take significant time (about 10 seconds), I try to cache results. The problem is that dependency structure is quite complicated, something like this: a* -> x, b* x -> c x, b* -> d where α -> β means that β depends on α values designated by *a*,*b*,*c*,*d* can be showed to user by request, and *x* is internal value values designated by letters with asterisk (*a**,*b**) can be edited by user Consider *x*. I have two values: xCache :: IORef X xUpToDate :: IORef Bool Initial state is: xCache <- newIORef undefined xUpToDate <- newIORef False Since *x* is evaluated once, I do xCache `writeIORef` x xUpToDate `writeIORef` True When user changes the value of *a *and saves it, all dependent on *a *values cache is expired: xUpToDate `writeIORef` False (recursively do it with all cache depends on *x*) When it comes to handling all *a,b,c,d,x *dependencies the code becomes a mess. I now have something like import Data.Functor import Data.IORef import Control.Monad data Mutable a = Mutable { ref :: IORef a, onChange :: IO () } change :: Mutable a -> a -> IO () change Mutable {..} a = ref `writeIORef` a >> onChange data Cache a b = Cache { fn :: a -> b, arg :: IORef a, cached :: IORef b, upToDate :: IORef Bool } expire :: Cache a b -> IO () expire Cache {..} = upToDate `writeIORef` False update :: Cache a b -> IO () update Cache {..} = do utd <- readIORef upToDate unless utd $ writeIORef cached =<< fn <$> readIORef arg test = do aRef <- newIORef undefined xRef <- newIORef undefined xCache <- Cache (^2) aRef xRef <$> newIORef False let aMut = Mutable aRef (expire xCache) aMut `change` 1 update xCache print =<< readIORef xRef -- 1 aMut `change` 2 print =<< readIORef xRef -- still 1 update xCache print =<< readIORef xRef -- now 4 I'd like to know if there is some library that could help me. (Sorry for my English) -- All the best, Alexey

4 3

Reachable variables exercise
by Carlos Camarao 16 Sep '10

16 Sep '10

Hi. Consider for example an expression e0 like: fst (True,e) where e is any expression. e0 should have type Bool IMHO irrespectively of the type of e. In Haskell this is the case if e's type is monomorphic, or polymorphic, or constrained and there is a default in the current module that removes the constraints. However, e0 is not type-correct if e has a constrained type and the constraints are not subject to defaulting. For example: class O a where o::a main = print $ fst(True,o) generates a type error; in GHC: Ambiguous type variable `a' in the constraint: `O a' arising from a use of `o' at ... Probable fix: add a type signature that fixes these type variable(s) A solution (that avoids type signatures) can be given as follows. The type of f e, for f of type, say, K=>t'->t and e of type K'=> t' should be: K +_t K' => t (not K U K' => t) where K +_t K' denotes the constraint-set obtained by adding from K' only constraints with type variables reachable from t. (A type variable is reachable if it appears in the same constraint as either a type variable free in the type, or another reachable type variable.) Comments? Does that need and deserve a proposal? Cheers, Carlos

2 2

Fwd: [Haskell-cafe] Reachable variables exercise
by Carlos Camarao 16 Sep '10

16 Sep '10

---------- Forwarded message ---------- From: Carlos Camarao <carlos.camarao(a)gmail.com> Date: Fri, Sep 17, 2010 at 12:01 AM Subject: Re: [Haskell-cafe] Reachable variables exercise To: Luke Palmer <lrpalmer(a)gmail.com> boolify o has type Boolable a => Bool under the proposal, then we have ambiguity, type error, right? In general, consider 'e' as (g:: K=>a -> t) (o:: O a=>a); then the type of 'e' has constraint (O a) iff 'a' occurs in t. Let's think about how could 'a' not occur in t. That happens if 'o' is not needed for computing the result; well, or, as in your example, 'g' is overloaded and requires the argument to resolve the overloading ('a' occurs in K and does not occur in t), in which case K=>t is ambiguous. Cheers, Carlos On Thu, Sep 16, 2010 at 6:56 PM, Luke Palmer <lrpalmer(a)gmail.com> wrote: > I am not totally sure if I understand your proposal correctly, but if > I do, then it has a flaw. Consider: > > class Boolable a where > boolify :: a -> Bool > > class O a where > o :: a > > main = print $ boolify o > > It seems like under your proposal this should not be a type error. > But if that is so, then what is its output? > > Luke > > On Thu, Sep 16, 2010 at 7:31 AM, Carlos Camarao > <carlos.camarao(a)gmail.com> wrote: > > Hi. Consider for example an expression e0 like: > > > > fst (True,e) > > > > where e is any expression. > > > > e0 should have type Bool IMHO irrespectively of the type of e. In Haskell > > this is the case if e's type is monomorphic, or polymorphic, or > > constrained and there is a default in the current module that removes > > the constraints. However, e0 is not type-correct if e has a > > constrained type and the constraints are not subject to > > defaulting. For example: > > > > class O a where o::a > > main = print $ fst(True,o) > > > > generates a type error; in GHC: > > > > Ambiguous type variable `a' in the constraint: > > `O a' arising from a use of `o' at ... > > Probable fix: add a type signature that fixes these type variable(s) > > > > A solution (that avoids type signatures) can be given as follows. > > > > The type of f e, for f of type, say, K=>t'->t and e of type K'=> t' > > should be: > > > > K +_t K' => t (not K U K' => t) > > > > where K +_t K' denotes the constraint-set obtained by adding from K' > > only constraints with type variables reachable from t. > > > > (A type variable is reachable if it appears in the same constraint as > > either a type variable free in the type, or another reachable type > > variable.) > > > > Comments? Does that need and deserve a proposal? > > > > Cheers, > > > > Carlos > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

1 0

Idea for hackage feature
by Mitar 16 Sep '10

16 Sep '10

Hi! I just got an idea for hackage feature. All functions/modules listed there could have some mark if they or any function/module they use uses an unsafe* function. Of course this will make probably almost everything marked as unsafe, but this is the idea - to raise awareness about that so that you can prefer some function/implementation over another. Of course marking/tagging everything as unsafe is not really useful. Because of this I propose that then community votes/vouches on correctness/stability of implementations and this would then influence the how unsafe given function really is (or is according to community, if we are more precise). Of course it would be even better that every function using unsafe would have also a formal proof but as we cannot believe that we will prove everything in a feasible feature we could maybe opt for such "crowd intelligence" approach. We cannot have a Turing machine, but maybe we can have crowd. ;-) (Of course low number of found bugs and good unit test code coverage can then positively influence crowd, so authors would be motivated to assure that.) Comments? Opinions? Because I really hate that I try to keep my code pure and separate IO from everything else and then somewhere deep in there some unsafe* lurks. (Ah, yes, a side effect of this tagging/marks would be also that you would be able to see where all those unsafe* calls are for a given function, so you would be able to fast jump (with link) to a given line in code and evaluate circumstances in which that unsafe* call is made. And then vote/vouch once you discover that it is probably pretty safe.) Mitar

9 11

IO Put confusion
by Chad Scherrer 16 Sep '10

16 Sep '10

Hello, I need to be able to use strict bytestrings to efficiently build a lazy bytestring, so I'm using putByteString in Data.Binary. But I also need random numbers, so I'm using mwc-random. I end up in the "IO Put" monad, and it's giving me some issues. To build a random document, I need a random length, and a collection of random words. So I have docLength :: IO Int word :: IO Put Oh, also putSpace :: Put My first attempt: doc :: IO Put doc = docLength >>= go where go 1 = word go n = word >> return putSpace >> go (n-1) Unfortunately, with this approach, you end up with a one-word document. I think this makes sense because of the monad laws, but I haven't checked it. Second attempt: doc :: IO Put doc = docLength >>= go where go 1 = word go n = do w <- word ws <- go (n-1) return (w >> putSpace >> ws) This one actually works, but it holds onto everything in memory instead of outputting as it goes. If docLength tends to be large, this leads to big problems. Oh, yes, and my main is currently main = L.writeFile "out.txt" =<< fmap runPut doc This needs to be lazier so disk writing can start sooner, and to avoid eating up tons of memory. Any ideas? Thanks! Chad

2 2