- Haskell-Cafe - Haskell.org

Re: Announce snm-0.0.2: Oops
by Johnny Morrice 27 Jul '10

27 Jul '10

> Sorry if I have left typos, it's very late I knew it was a bit late to be uploading things, I forgot to say where anyone interested might download this: it's on Hackage so just cabal install snm Cheers Johnny

1 0

Instances for Set of Functor, Traversable?
by Gregory Crosswhite 27 Jul '10

27 Jul '10

Is there a specific reason why Set doesn't have instances for Functor and Traversable? Or have they just not been written yet? :-) Cheers, Greg

3 2

Re: [Haskell-cafe] data type declaration
by John Lato 26 Jul '10

26 Jul '10

> From: Patrick Browne <patrick.browne(a)dit.ie> > > Andrew, > Thanks for your detailed feedback, it is a great help. > I appreciate that the code does not do anything useful, nor is it an > appropriate way to write Haskell, but it does help me > understand language constructs. I have seen statements like > >>>> data C3 c3 a => Address c3 a = Address c3 a > Incidentally, there seems to be a consensus that this a Bad Idea [1]. Even when you specify a type class context on a data declaration, Haskell still requires you to specify the context on functions that use that data (Address c a). What's worse is that you need the class restriction for *all* functions that use an Address, even if they don't operate on the component parts and don't make use of the type class at all. Basically, it ends up making all your type signatures longer with no benefit. If you really want to ensure that every "Address c a" has this context, then use a smart constructor: address :: C3 c3 a => c3 -> a -> Address c3 a address = Address and don't export the Address data constructor. Also, Andrew said that type classes are closer to Java interfaces than C++ objects. This is true, but you may find the difference useful too. A small example of a common OOP-er mistake should demonstrate: -- return a Float if True, else an Int. At least it would if type classes were interfaces. toFloat :: Num a => Int -> Bool -> a toFloat x True = (fromIntegral x) :: Float toFloat x False = x OOP-style interfaces have two features: they specify methods that are available for all types which implement the interface, and they are an existentially-quantified data constructor. Equivalent code in Java would return an existentially-quantified type - we know the interface methods are supported but not the data type, so the interface methods are all we can do. The exact type (either Float or Int) is wrapped in this existentially quantified box. Haskell type classes don't do existential quantification, which is why the above doesn't compile. The return value of this function must be any a with a Num instance, and the caller (not toFloat) gets to choose the exact type to instantiate. Translating an interface to Haskell requires that you write both parts: class Num a where ... data INum = forall a. Num a => INum a --requires the ExistentialQuantification extension -- now toFloat works toFloat :: Int -> Bool -> INum toFloat x True = INum ((fromIntegral x) :: Float) toFloat x False = INum x Now the type variable is stuck in the INum type instead of being universally quantified (top-level forall), which is what an interface does. I think most Haskellers would prefer to choose a design that doesn't require existential quantification, but it really depends on the problem. John [1] GHC sources refer to this context as "stupid theta", see further discussion at http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts

3 4

Typeclasses question in "Real World Haskell" book
by Angel de Vicente 26 Jul '10

26 Jul '10

Hi, I'm stuck at page 151 of Real World Haskell and hoping that perhaps some of you can give me a hand here... The code that is giving me trouble is below. data JValue = JString String | JNumber Double | JBool Bool | JNull | JObject [(String, JValue)] | JArray [JValue] deriving (Eq, Ord, Show) type JSONError = String class JSON a where toJValue :: a -> JValue fromJValue :: JValue -> Either JSONError a instance JSON JValue where toJValue = id fromJValue = Right instance JSON Bool where toJValue = JBool fromJValue (JBool b) = Right b fromJValue _ = Left "not a JSON boolean" I don't understand how the JSON typeclass is defined, in particular the fromJValue definition. For instance, when defining the instance for Bool types, then I understand that both functions (toJValue and fromJValue) will be called upon when we supply a Bool type, but then the (JBool b) type in function fromJValue doesn't match.... toJValue is no problem, but I cannot understand how fromJValue is supposed to work, and the comments in the online book (http://book.realworldhaskell.org/read/using-typeclasses.html) don't help with this either. *Main> :load ch6 [1 of 1] Compiling Main ( ch6.hs, interpreted ) Ok, modules loaded: Main. *Main> toJValue False JBool False *Main> :type it it :: JValue *Main> fromJValue False <interactive>:1:11: Couldn't match expected type `JValue' against inferred type `Bool' In the first argument of `fromJValue', namely `False' In the expression: fromJValue False In the definition of `it': it = fromJValue False *Main> fromJValue (JBool False) <interactive>:1:0: Ambiguous type variable `a' in the constraint: `JSON a' arising from a use of `fromJValue' at <interactive>:1:0-23 Probable fix: add a type signature that fixes these type variable(s) *Main> Any pointers? Thanks a lot, Ángel de Vicente -- http://www.iac.es/galeria/angelv/ High Performance Computing Support PostDoc Instituto de Astrofísica de Canarias --------------------------------------------------------------------------------------------- ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en

4 6

Please report any bug of gtk2hs-0.11.0!
by Andy Stewart 26 Jul '10

26 Jul '10

Hi all, We plan to release bug fix version : gtk2hs-0.11.1 Please report any bug of gtk2hs-0.11.0, we will fix it before release gtk2hs-0.11.1 We plan to add many new APIs in gtk2hs-0.12.0, so gtk2hs-0.11.1 will be the last stable version with current APIs. Thanks for your help! -- Andy

6 9

ANNOUNCE: darcs 2.5 beta 2
by Reinier Lamers 26 Jul '10

26 Jul '10

Hi all, The darcs team would like to announce the immediate availability of darcs 2.5 beta 2 (also known as darcs 2.4.98.2 due to Cabal restrictions). Important changes since darcs 2.4.4 are: * trackdown can now do binary search with the --bisect option * darcs always stores patch metadata encoded with UTF-8 * obliterate has a -o flag to save obliterated patch * amend-record now supports --ask-deps * apply now supports --match * amend-record has a new --keep-date option * inventory-changing commands (like record and pull) now operate in constant time with respect to the number of patches in the repository * the push, pull, send and fetch commands no longer set the default repository by default * the --edit-description option is now on by default for the send command If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install darcs-beta Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.4.98.2.tar.gz and build it by hand as explained in the README file. Kind Regards, the darcs release manager, Reinier Lamers

1 0

datatype contexts
by Gregory Crosswhite 26 Jul '10

26 Jul '10

I agree with prior discussion on this list that adding contexts to datatype declarations seems to be more trouble than its worth, since these contexts just have to be added again to every function using the datatype. However, I have often wondered: why do function *have* to have these contexts? What would it affect in the language if we made the contexts be implicit, so that if we have data Datatype a = Context a => Datatype a then for function declarations f :: D a -> ... the context "Context a" is automatically asserted by the compiler? Cheers, Greg

3 3

ANN: Moio, a library for compositional event-driven programming
by Patai Gergely 26 Jul '10

26 Jul '10

Hello all, I created a little library that provides first-class event sources and event stream transformers, both allowing side effects. For the time being, the code is only available on GitHub [1]. The library is called Moio, short for 'multiple-occurrence I/O', since event sources are effectively a generalisation of the IO monad that outputs a stream of values over time instead of just a single result at the end of its execution. To summarise in a short phrase, Moio could be considered as 'Rx meets Fudgets', but that's only a superficial characterisation. Check out the example application, a simple bulletin board server, which shows how to treat a callback-based GTK GUI and blocking I/O based networking uniformly using the abstractions provided. Gergely [1] http://github.com/cobbpg/moio -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again

1 0

Techniques for ensuring parser correctness?
by Jason Dagit 26 Jul '10

26 Jul '10

Hello, I find that parser correctness is often hard to verify. Therefore, I'm interested in techniques that others have used successfully, especially with Haskell. Techniques I'm aware of: * Round trip checks: Generate a datastructure, render as a string, parse back, and compare. Quickcheck can be used to automate this. * Fuzz testing: What tools exist to help me? * Formal verification: Has anyone been using this with Haskell parsers? Other than general theorem provers, say Isabelle, what tools exist? My specific need: The immediate challenge I have is that I'm modifying the parser that Darcs uses and we would like to improve the parser's test suite as well. The parser abstraction used in this case follows parsec's API. Left to my own devices I would use round trip checks, written with quickcheck, for this exercise. Because we're using a parsec style parser, I don't have a nice neat grammar handy. Thanks in advance for any advice you have! Thanks, Jason

4 6

How to do this with associated types?
by Alexey Karakulov 26 Jul '10

26 Jul '10

Suppose I have one piece of code like this: > class Result r e | r -> e where > failure :: e -> r a > success :: a -> r a > at :: Result r String => [a] -> Int -> r a > at xs i = if i >= 0 && i < length xs > then success (xs !! i) > else failure "Wrong index" Either instance of Result is quite straightforward: > instance Result (Either e) e where > failure e = Left e > success x = Right x Maybe instance is discarding failure information: > instance Result Maybe e where > failure _ = Nothing > success x = Just x Some tests it in ghci: ghci> let xs = [0,1,2] ghci> at xs 2 :: Either String Integer Right 2 ghci> at xs 3 :: Either String Integer Left "Wrong index" ghci> at xs 2 :: Maybe Integer Just 2 ghci> at xs 3 :: Maybe Integer Nothing I'd like to replace functional dependencies with type families (associated types in my case): > class Result r where > type Failure > failure :: Failure r -> r a > success :: a -> r a Either instance is ok: > instance Result (Either e) where > type Failure (Either e) = e > failure e = Left e > success x = Right x But what to do with Maybe? > instance Result Maybe where > type Failure Maybe = forall e. e -- can't do this > failure _ = Nothing > success x = Just x

3 2