March 2011 - Haskell-Cafe

Re: [Haskell-cafe] Use of uninstantiated type class
by John Lato 05 Mar '11

05 Mar '11

> Message: 8 > Date: Sat, 5 Mar 2011 00:45:33 +0100 > From: Yves Par?s <limestrael(a)gmail.com> > Subject: [Haskell-cafe] Use of uninstantiated type class > To: Haskell-Cafe <haskell-cafe(a)haskell.org> > Message-ID: > <AANLkTimBg5TyG6ZNWCKaOT9dP=QE95MtC=q_t7RRPQgv(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > For testing purposes, I am trying to make an overlay to IO which carries a > phantom type to ensure a context. > I define contexts using empty type classes : > > class CtxFoo c > class CtxBar c > > The overlay : > > newtype MyIO c a = MyIO (IO a) > > Then I define some methods that run only a specific context : > > runFoo :: (CtxFoo c) => MyIO c a -> IO a > runFoo (MyIO x) = x > > runBar :: (CtxBar c) => MyIO c a -> IO a > runBar (MyIO x) = x > > And then an action that runs in context 'Foo' : > > someAction :: (CtxFoo c) => MyIO c () > someAction = putStrLn "FOO" > > Then I run it : > > main = runFoo someAction > > But obiously, GHC complains that my type 'c' remains uninstantiated : > > Ambiguous type variable `c' in the constraint: > (CtxFoo c) arising from a use of `runFoo' > Probable fix: add a type signature that fixes these type variable(s) > In the expression: runFoo someAction > In an equation for `main': main = runFoo someAction > > > Is there a way to deal with this ? > The interest of using type classes and not empty types to represent the > contexts is that it stays simple, and that I can do that : > > someAction2 :: (CtxFoo c, CtxBar c) => MyIO c () > someAction2 = putStrLn "FOO and BAR" > > ... a function that can run in both contexts. > You can accomplish this with Rank2Types (and ScopedTypeVariables). Try this: class CtxFoo c class CtxBar c data Ctx instance CtxFoo Ctx where instance CtxBar Ctx where runFoo :: forall a. (forall c. (CtxFoo c) => MyIO c a) -> IO a runFoo x = case (x :: MyIO CtxFooD a) of (MyIO x') -> x' It's useful to compare the type of this "runFoo" with the old "runFoo" *Main> :t runFoo runFoo :: (forall c. CtxFoo c => MyIO c a) -> IO a *Main> :t runFooOld runBar :: CtxFoo c => MyIO c a -> IO a Note that the "c" type var is no longer universally quantified. This means that "runFoo" can't be used with any actions that specify a concrete context, the action must specify only the "CtxFoo" type class. There's a drawback to this approach though. The number of "run" functions is combinatorial in the number of contexts. With only two contexts, you already need "runFoo", "runBar", and "runFooBar". Unless you'll only ever need a single context, or you won't need to have combinations of them, this approach quickly grows unwieldy. John

1 0

Thoughts on program annotations.
by Jason Dusek 05 Mar '11

05 Mar '11

Hi List, I am working on a Bash config generation system. I've decided to factor out the Bash AST and pretty printer, here in a pre-release state: https://github.com/solidsnack/bash One thing I'd like to support is generic annotations, so that at a future time I can add (and render) comments, mark subscripts with what privilege (package install, sudo) they require or otherwise characterize the script outside its lexical structure. I ended up making my statement type a Functor with a Foldable instance. Given that every statement has an annotation, it seemed better to me to use mutually recursive datatypes, using one datatype to capture "annotatedness", like this: -- From https://github.com/solidsnack/bash/blob/c718de36d349efc9ac073a2c7082742c456… data Annotated t = Annotated t (Statement t) data Statement t = SimpleCommand Expression [Expression] | ... | IfThen (Annotated t) (Annotated t) | ... I wonder what folks think of this approach? It does mean I end up with all leaf-level annotations being potentially without annotations; this allows for relatively generic definitions, on the one hand; but forces type annotations at the use-site in many cases. It also means I have mutually recursive Functor and Foldable instances. Another option for annotations would be a sort of tree of zippers pointing in to the statement tree; this seems horrible at first glance since it leaves open the question of how the annotations are associated with their nodes in the first place. However, it does have the nice feature of simplifying the type of statements and also is just much more modular feeling. What does the list think? -- Jason Dusek Linux User #510144 | http://counter.li.org/

4 5

ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)
by Michal Konečný 04 Mar '11

04 Mar '11

Dear all, I am pleased to announce hmpfr-0.3.2, a new version of Aleš Bizjak's bindings to the MPFR arbitrary precision floating point arithmetic library. The changes in this version are quite small but significant: - support for MPFR 3.0.0 as well as MPFR 2.4.* - dependency on integer-simple instead of integer-gmp The latter is most significant because unfortunately it makes it rather more difficult to install hmpfr. Currently almost all binary distributions of ghc have integer-gmp compiled in to provide the Integer type via the standard GMP library. Also haskell platform 2010.2.0.0 assumes that ghc has been compiled with integer-gmp although it makes no specific use of it. Instructions on how to compile ghc and haskell platform with integer-simple instead of integer-gmp are on: http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP The rationale for this change is the fact that despite much effort hmpfr is very unreliable on ghc that includes integer-gmp due to ghc deallocating GMP data that was allocated by MPFR at unpredictable times. Aleš and I hope that hmpfr can return to using integer-gmp once the proposal http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinRepl… to replace gmp with a modified gmp in ghc is implemented and made the default. Best regards, Michal -- |o| Michal Konecny <mikkonecny(a)gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston

3 5

Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)
by Michal Konečný 04 Mar '11

04 Mar '11

Hi Dan, On Friday 04 Mar 2011 21:59:12 Daniel Peebles wrote: > I'm adding Ed to the conversation as he's very interested in this topic, > too. I do apologise - I was meant to post the previous email back to haskell-cafe but by mistake it went only to you. I hope you do not mind that I am taking the discussion back to the cafe. I attach my email so that other readers of the cafe can see it. > The experts were right about it being impossible to work with GHC's > GMP – until recently. "foreign import c" calls are indeed going to call GC > when you don't want it, but when they split integer-gmp out of GHC's own > RTS, Duncan Coutts (one of those experts) added the "foreign import prim" > construct so that he could do exactly what you want, and operate on GMP > integers with GHC-allocated memory without worrying about temporary > storage blowing up while you aren't looking. > > So in general, I'd lean more towards replacing all your ccall bindings to > MPFR with cmm bindings. It does require some GHC internals knowledge but > is fairly mechanical, and would solve all the problems, without requiring > a rewrite of GMP (that would be slower anyway). > > Ed is actually going to get started on a fairly simple binding to a subset > of MPFR for one of his projects, using the CMM approach based on the > structure of my natural-gmp package > (https://github.com/pumpkin/natural-gmp, which is itself based heavily on > integer-gmp, but reworked to work fine from cabal rather than depending on > GHC's build process). Once he is done with that, you might want to refer > to his implementation to make your more complete MPFR binding work with > integer-gmp (and thus make no speed sacrifices). If this is the best approach, I would welcome help with this as I will not have much time to work on it until the summer due to teaching commitments and the need to publish work done earlier. > I would also like a gmp-compatible replacement, but it's going to > necessarily be slower and would prefer to be able to have fast > computations over floating-point numbers AND integers/naturals. Eek, I made a mistake, I apologise again - the proposal I was quoting in the announcement is not what I had in mind. I was meant to refer to a mention by igloo at the very end of http://hackage.haskell.org/trac/ghc/ticket/311 which is a very different proposal from the one I linked to and the one you seem to refer to here. I was not at all thinking of writing a gmp compatible replacement. I was thinking of taking gmp sources and mechanically modify the exported names and modify integer-gmp to use those modified names. Thus there would be no difference in the speed of Integer as it would still use an exact clone of the original gmp in exactly the same way as now but not interfere with what the usual gmp code does via other libraries. Please correct me if I this approach is not feasible or if there is some advantage in using cmm over this proposal that I am missing. Michal -- |o| Michal Konecny <mikkonecny(a)gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston

1 0

Announce: new releases of bitset and funsat
by Denis Bueno 04 Mar '11

04 Mar '11

Hello all, Just a small announcement. funsat has been bumped to 0.6.2. New in 0.6.2: works with ghc-6.12 and fixed some space leaks. http://hackage.haskell.org/package/funsat bitset has been bumped to 1.1. New in 1.1: can easily convert between the BitSet representation and the underlying Integer. http://hackage.haskell.org/package/bitset -- Denis

1 0

darcs hacking sprint #6 (1-3 April, Paris)
by Eric Kow 04 Mar '11

04 Mar '11

Hi everybody, Following up on my last message, the date and venue for the sixth Darcs Hacking sprint has been confirmed. Get out your berets everybody, because we're going to Paris! Here are three things to know 1. Everybody is welcome to join us. We'd love to have you, whatever your Haskell or Darcs hacking experience. Also, if you've got a wacky idea for the future of version control, or a cool use for the Darcs library, you should join us too :-) 2. Please let us know if you're attending. Just add your name to http://wiki.darcs.net/Sprints/2011-04 and you're good to go. You can also send us an email. 3. We can reimburse travel costs (within reason!). Let us know if you'd like a reimbursement, and save your receipts. Many thanks to everybody who participated in our fundraising drives or who gave money on the side. Thanks also to the Software Freedom Conservancy for making fundraising and reimbursements so painless! If you can't join us in person, but you'd like to cheer us on, say hello at http://darcs.net/donations.html! Looking forward to seeing you! Eric PS. Berets optional. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> For a faster response, try +44 (0)1273 64 2905 or xmpp:kowey@jabber.fr (Jabber or Google Talk only)

1 0

A practical Haskell puzzle
by Yitzchak Gale 04 Mar '11

04 Mar '11

You have written a large software system in Haskell. Wishing to play to Haskell's strength, you have structured your system as a series of composable layers. So you have data types Layer1, Layer2, ... and functions layer2 :: Layer1 -> Layer2 layer3 :: Layer2 -> Layer3 ... etc. Of course you'll want to be able to run any range of the layers separately, at least for testing and debugging purposes if not for the functionality itself. So your UI module (command line or whatever) that launches your application provides a data type data Layers = Layers Int Int that indicates which layers to run, and functions deserialize1 :: L.ByteString -> Layer1 deserialize2 :: L.ByteString -> Layer2 ... serialize1 :: Layer1 -> L.ByteString serialize2 :: Layer2 -> L.ByteString ... etc. Now you need a function runLayers :: Layers -> L.ByteString -> L.ByteString so that the effect is for example runLayers (Layers 4 6) = serialize6 . layer6 . layer5 . deserialize4 Typically there could be 20 or 30 layers, so writing out each case could result in hundred of boilerplate definitions for runLayers. Scripting the generation of all that boilerplate, e.g. using TH, doesn't seem very attractive either. On the other hand, it seems silly to have to use super-advanced type olegery for such a trivially simple yet centrally important component of the system. What is the best way to write runLayers? Feel free to change the details of the above design, as long as it meets the functionality requirements expressed. Regards, Yitz

7 16

ANN: Haskell XML Toolbox Version 9.1
by Uwe Schmidt 04 Mar '11

04 Mar '11

Haskell XML Toolbox 9.1 I would like to announce an update hxt-9.1 of the Haskell XML Toolbox. Main changes compared to hxt-9.0 are * space optimization of DOM tree for better performance for lager XML documents * optimization of space used during parsing in native XML and HTML parsers * a binding to the expat parser via hexpat Cheers, Uwe

1 0

Getting started with http-enumerator
by C K Kashyap 04 Mar '11

04 Mar '11

Hi, I'd like to use http-enumerator for things that I've been using perl/Lwp for. I tried looking but was not able to find good documentation for it. Could someone please point me to simple examples? Like posting a form, dealing with cookies etc. Regards, Kashyap

1 0

Project structure
by Hauschild, Klaus (EXT) 04 Mar '11

04 Mar '11

Hi Haskellers, is there a recommended structure for Haskell projects. I like the Maven way (http://maven.apache.org/guides/introduction/introduction-to-the-standard-di…) for Java projects. How to separate productive from test code, how to separate source code from other resources? Thanks Klaus

2 1