- Haskell-Cafe - Haskell.org

Exceptions during exception unwinding
by Brian Bloniarz 01 Oct '09

01 Oct '09

I had a question about onException & friends: what's the rationale for having: (error "foo") `onException` (error "bar") give bar and not foo? I.e. why does an exception raised during exception handling get propagated past the exception that triggered the handler? Most examples I can think for exception unwinding code would prefer the original exception be propagated -- for example, HDBC has a function which rolls back a DB transaction on exception; it implements it like so: > withTransaction conn func = > do r <- onException (func conn) doRollback > commit conn > return r > where doRollback = > -- Discard any exception from (rollback conn) so original > -- exception can be re-raised > Control.Exception.catch (rollback conn) doRollbackHandler > doRollbackHandler :: SomeException -> IO () > doRollbackHandler _ = return () IMHO, it'd be easier to just write: > withTransaction conn func = > do r <- onException (func conn) (rollback conn) > commit conn > return r This same argument applies to bracket, bracket_, bracketOnError & finally; even the common: > bracket openSomeHandle closeSomeHandle doAction If some error arises during doAction, there's a chance closeSomeHandle might fail (even a good chance, given that exception unwinding paths are usually poorly tested), and probably doAction has more accurate information about what went wrong than closeSomeHandle. This is just a thought; I hadn't seen this discussed somewhere. I know for example that Java has the same approach as the current Control.Exception, so there must be good arguments for that too. One that I can think of: using onException to rethrow an exception as a different type, though that's what mapException is for, correct? Thanks, -Brian _________________________________________________________________ Microsoft brings you a new way to search the web. Try Bing™ now http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_… bing_1x1

3 3

Fwd: Uniplate + strict fields = fail. Why?
by Dmitry Astapov 01 Oct '09

01 Oct '09

Hi, I've been playing with generics in general (pardon the pun) and Uniplate in particular, and found out that strict data fields somehow derail Uniplate. Observe: === code === {-# LANGUAGE DeriveDataTypeable #-} module Test where import Data.Generics (Data(..),Typeable(..)) import Data.Generics.PlateData import Data.ByteString import Data.ByteString.Char8 as C data Foo = Foo String deriving (Show, Data, Typeable) tst1 = [ Foo "a", Foo "b" ] test1 = [ show x | Foo x <- universeBi tst1 ] -- *Test> test1 -- ["\"a\"","\"b\""] data Bar = Bar ByteString deriving (Show, Data, Typeable) tst2 = [ Bar (C.pack "a"), Bar (C.pack "b") ] test2 = [ show x | Bar x <- universeBi tst2 ] -- *Test> test2 -- *** Exception: Prelude.undefined === end of code === First, I thought that instance of Data for ByteString is somehow deficient, but this is not the case. If you change definition of Foo to "data Foo = Foo !String", you would get the same error with "Prelude.undefined". Since all fields in ByteString constructors are strict, I have no joy trying to use it with Uniplate. Howere, my type-foo is not strong enough to understand what's wrong. Could someone give me a hint? PS ghc 6.10.4 uniplate 1.2.0.3 bytestring 0.9.1.4 PPS Neil Mitchell is receiving a copy of this email -- Dmitry Astapov

2 1

Re: [Haskell-cafe] Any generic serializer to String? was: Any working example of using genericserialize?
by Dimitry Golubovsky 01 Oct '09

01 Oct '09

Hi, On 9/30/09, Jason Dagit <dagit(a)codersbase.com> wrote: [skip] > Seems like using withList is wrong or the deserializer is simply buggy. It > certainly doesn't work the way I would expect SExp reading to work. I also > notice from reading the source on hackage that there may not be any tests > for this package and it is a 0.1 release. I'd contact the author, as it > seems there is a deficiency in the documentation or a bug in the > implementation. Thanks Jason for trying this. The genericserialize package is probably not finished yet. What else exists that could be used to serialize in generic way (i. e., anything that is an instance of Data and Typeable) into a string? It does not need to be very efficient as structures to be serialized are not huge (but may be pretty complex), and serialization is a part of an utility not to be used frequently. It only needs to "just work". One thing I thought of was to serialize to JSON (there is a generic serializer in one of packages although I did not test it other way) which has higher overhead than S-expressions though. Any other thoughts? Thanks. -- Dimitry Golubovsky Anywhere on the Web

4 5

ANNOUNCE: SourceGraph 0.5.1.0
by Ivan Lazar Miljenovic 01 Oct '09

01 Oct '09

This is an updated version of my graph-theoretic static analysis tool for Haskell, SourceGraph. This version is available from http://hackage.haskell.org/package/SourceGraph-0.5.1.0 (now with docs on the Hackage page!). This version provides the ability to pass in a single Haskell source file rather than a Cabal file for analysis purposes. Note that the Cabal version is still preferred as it is better able to determine the project name and which modules are exported: when using a single source file, that file is presumed to be the only exported module and its module name is used as the overall project name. This feature was requested by Curt Sampson. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

Journals on Haskell and FP?
by Eugene Kirpichov 01 Oct '09

01 Oct '09

Hi. I was going to add a reference to the recently born Russian journal "Practice of functional programming" (http://fprog.ru/ ; had its 1st issue in July and 2nd was Sep.28) to haskellwiki into a section devoted specifically to journals, but it turned out there is no such section and, consequently, no information on journals: just books, tutorials and research papers. I think this is very valuable information and it's a shame that it's not listed on haskellwiki. So, I added such a subsection to http://haskell.org/haskellwiki/Books_and_tutorials#Journals and added a reference to Monad.Reader (the only other openly available journal on FP that I am aware of) , and I encourage the community to mention some more journals there. I also encourage the Russian readers who have not yet seen the aforementioned journal to give it a look :) -- Eugene Kirpichov Web IR developer, market.yandex.ru

1 0

error on "--++ bla bla bla"
by Hong Yang 01 Oct '09

01 Oct '09

Hi, I got an error if one of lines reads "--++ bla bla bla" where I tried to comment, but "-- ++ bla bla bla" (notice the space after "--") is OK. Do you think this revealed a tiny bug in the GHC compiler (I am using Windows Haskell Platform 2009.2.0.2)? Thanks, Hong

5 7

combinatorial search with running bound
by Michael Mossey 01 Oct '09

01 Oct '09

I have a combinatorial search problem that requires a running lower bound to be tracked in order to prune the search. I have enough Haskell experience to know how to do a combinatorial search, for example with list compresions or the list monad, but I don't know how to keep a running lower bound. The problem is: I have two groups of boxes, and need to figure out how closely the centers of the groups can be brought left-right. For example, 55 11111 55 11111 44 22 44 22 + <- how close? -> + 33333 6666 33333 6666 33333 The left group consists of boxes 1, 2, and 3, which have both a size and a position (the position is relative to the center of the group, represented with the +). The right group has boxes 4, 5, and 6. The problem is to determine how closely the groups can be brought together without any boxes intersection. The basic algorithm is to consider each pair of boxes and ask if they have any "vertical overlap"---if so, figure out how closely they can be brought together without intersecting, otherwise ignore them. Then take the maximum of those numbers. -- (Here assume lrSeparation returns minBound for boxes that don't have -- vertical intersection.) boxesSep :: [Box] -> [Box] -> Int boxesSep lefts rights = maximum [ lrSeparation l r | l <- lefts, r <- rights ] However, this algorithm can be improved by pruning. - Define the 'left extent' of a box by how far its left edge sticks out to the left of the group center. Similarly the 'right extent'. - Sort the list of left boxes in the order of decreasing right extent. Sort the list of right boxes in order of decreasing left extent. - Consider pairs of boxes as a kind of outer loop on the left boxes, and inner loop on the right boxes. - Track the current maximum required separation, which is a lower bound on the final answer. - If at any point in the inner loop, the right extent has gotten so small that there's no way you could find a new maximum, skip the rest of the inner loop (skip the remainder of the right boxes). Here's my attempt to write this using a state monad. There's probably a more idiomatic way to do it. -- This is state used in the state monad. data SearchState = SearchState { -- running maximum: ssMaximum :: Int -- remember the full list of right boxes -- so we can initiate a new outer loop , ssRights :: [Box] } boxesSep2 :: [Box] -> [Box] -> Int boxesSep2 lefts rights = let ls = sortBy ((flip compare) `on` rightExtent) lefts rs = sortBy ((flip compare) `on` leftExtent) rights in fst $ runState (boxesSep2' ls rs) (SearchState minBound rs) boxesSep2' :: [BoxBounds] -> [BoxBounds] -> State SearchState Int -- Termination of algorithm: boxesSep2' [] _ = gets ssMaximum -- Initiate a new inner loop: boxesSep2' (l:ls) [] = do rights <- gets ssRights boxesSep' ls rights -- Common case: boxesSep2' lss@(l:ls) (r:rs) = do -- In this way of writing the code, we distinguish between the -- left/right separation which is the sum of the extents, and the -- question of whether there is vertical overlap. let v = isVerticalOverlap l r sep = lrSeparation l r ss <- get let max = ssMaximum ss if sep <= max then boxesSep' ls (ssRights ss) --Here we "prune" (initiate new inner loop) else do -- Update max is needed: when v (put ss { ssMaximum = sep }) boxesSep' lss rs So if there is a better way to do this, I'm all ears.

3 5

Fwd: [Haskell-cafe] Market Place for Haskell development teams?
by Alberto G. Corona 01 Oct '09

01 Oct '09

Curt, 2009/9/29 Curt Sampson <cjs(a)starling-software.com> > On 2009-09-29 13:18 +0200 (Tue), Alberto G. Corona wrote: > > > Java is part of the Java platform, that brought OS independence and > > interoperability at the right time. .Download-execution on the client > > was also a reason for the initial success of Java in the Internet era. > > I was a die-hard Java hacker from 1999 until some undetermined time in > the early-to-mid-2000s. (I abandoned it more or less completely sometime > around late 2005, if I recall correctly.) > > This may be somewhat anecdotal evidence, but I disagree with both > of your statements here. > Of course, I´m not talking about real advantages of Java or any PL. I told about the reasons that people used at the time to introduce the language in the mainstream, either is desirable this for haskell or not. I think it is. Nobody consider the runtime download of Java code important nowadays. Not even the cross-platform features. but it was marketeed at his time as such. > > Rubi and Python came with libraries targeted to Rapid development of > > Internet applications. > > No, neither originally "came" with that. > Rubi and Pyton came into existencie without their internet libraries, but they would´nt be popular without them. Although I conffess I don´t know the history in detail. > > What is the vehicle that haskell can use to enter the mainstream?. > > That may be the wrong question. "Avoid success at all costs" still > rings true to me. A year or so ago I seemed like one of the few on > the haskell-libraries list voting in favour of fixing API problems in > libraries, rather than etching in stone those problems in the name of > backwards compatibility so that we could "become more popular." > > Said above. We have different goals. > Do you really want, in 2020, to look back at the 2010 revision of the > Haskell standard and think, "we entrenched things that for a decade > everybody agreed was dumb"? > I see no problem in haskell having both. experimental and fixed versions. Haskell 2020 for you and me and haskell 2010 for my commercial code. Both woukd ve maintained and enriched by far more people. > > I can tell you, even when you're a Java enthusiast, there's nothing > more depressing than looking at java.util.Date and thinking, "That > should have been immutable, but it's going to be mutable for the rest of > eternity. We will never fix that." > > But let's try this again: > > > What is the vehicle that haskell can use to enter the mainstream?. > > Become more stupid. > > Is that a better answer? I'm not just a geek; I do marketing too (this > is what happens when you start your own company), and if you asked me, > using the utmost of my technical knowledge and marketing skills, to make > Haskell popular, this is what I'd recommend. > > Become more stupid may mean "give exactly what the people want" that transaltes to be more stable, give libraries, platforms etc. That is not a extra effor. that will come naturally as more people use the language. some people is naturally more abstract. some are more practical. > (I suppose it's a sign of my professionalism that to do this would > nearly break my heart, but if you wanted me to tell you the best way to > do this, and I couldn't tell you to get lost, that's what I'd say.) > > > Many people will play with Haskell in the spare time, and many of them > > will be permitted to develop some non critical applications at work. > > But that is all. > > Hm. So I suppose that this options trading system I'm working on, which > is the sole way our business makes money and is entirely written in > Haskell, doesn't actually exist. > > Congratulations.!! > > I think that all the current niches are filled, but new niches are > coming. > > Haskell already has a good niche. In fact, a brilliant one. We have > a whole bunch of academics doing truly wonderful stuff (imagine the > world without monads!--thank you Philip Wadler (and Eugenio Moggi)) > that the rest of us (relatively) dumb idiots can use to make our lives > better. We've got several very good implementations of the language, > one of which is a truly shit-hot compiler[1]. And we can use that to do > commercial applications quite comfortably[2]. > > Right. ;) > My personal opinion is, yes, let's let Haskell stick to the niche where > it's great, but it changes so fast that it's scary to everybody else. To > echo Paul Graham, I'm extremely happy to see my competition use Java. > > [1] Like that's so important. Ruby's standard implementation to this day > is an interpreter that implements all the popular extensions and has a > reasonably decent FFI. In Haskell-land, we call that "Hugs." It's only > because we have GHC as well that we can look down on Hugs; in the Ruby > (and Python, and PHP) worlds, they're saying that interpreters are just > fine for all sorts of "enterprise applications." > > [2] (Warning: self-promotion): > http://www.starling-software.com/misc/icfp-2009-cjs.pdf > > > Financial applications are an example of higher level programming > > where tasks usually performed by humans are now automatized and there > > is no or few traditions about that. The need to think at a higher > > level without being worried by side effects and other details are > > specially needed in such kind of areas. That's where haskell could > > have its own niche. > > Actually, I think that Haskell has a niche there not because of that > sort of thing, but merely because it's better than Java at doing what > Java does well, but scary enough that only small groups of brave > people who are comfortable with risk would ever attempt to use it. The > financial sector happens to have a lot more of those than many others. > > same concept in more plain words. I guess. > cjs > -- > Curt Sampson <cjs(a)starling-software.com> +81 90 7737 2974 > Functional programming in all senses of the word: > http://www.starling-software.com >

5 4

convert a list of booleans into Word*
by Paul.Brauner＠loria.fr 01 Oct '09

01 Oct '09

Hello, I haven't found a function in hackage or in the standard library that takes a list of booleans (or a list of 0s and 1s, or a tuple of booleans or 0s and 1s) and outputs a Word8 or Word32. I have written one which seems very inefficient : toWord8 :: [Bool] -> Word8 toWord8 bs = go 0 0 bs where go n r [] = r go n r (b:bs) = go (n+1) (if b then setBit r n else clearBit r n) bs Is there a better way to do this out there ? (If it helps, i'm writting a toy compression algorithm, which outputs binary as lists of booleans, and I'd like to output that in a file). Cheers Paul

9 11

type class question
by Ben 30 Sep '09

30 Sep '09

dear haskellers -- i'm trying this question again, in haskell-cafe. i got some responses in haskell-beginners but am looking for more guidance. also, i understand this functionality is encapsulated in the Workflow module in hackage, but i'd like to understand this myself. this email is an (il)literate haskell file. suppose i have class of computations a -> State s b. for concreteness, let's say i'm writing a library of on-line statistical summary functions, like > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-} > > module Foo where > > import Control.Monad > import Control.Monad.State > import Control.Monad.State.Class > > data RunningAverageState = S Double Int > > runningAverage :: Double -> State RunningAverageState Double > runningAverage v = do > S sum count <- get > let nsum = sum + v > ncount = count + 1 > put $ S nsum ncount > return $ nsum / (fromIntegral ncount) > > test = take 10 $ evalState (mapM runningAverage [1..]) $ S 0 0 test -> [1.0,1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5] here "on-line" means that we may be taking data from an intermittant external source, e.g. a data generator IO [Double], say, and want to be able to feed the summarizer datum one-by-one, and produce intermediate summaries. also we may want to be able to serialize our computation state (with Data.Binary, say) so that we can resume data collection and summarization later. naturally i want to create some common higher order operations on these primitives, like applying them to a stream of data, or combining them in some way. it seems that one would want some kind of type class to define a common interface to them. > class (MonadState s m) => Summarizer s m | m -> s where > initialState :: s > runOne :: Double -> m Double > where initialize puts some intial state into the system, and runOne collects and summarizes the next piece of data. an instance for runningAverage would look like > instance Summarizer RunningAverageState (State RunningAverageState) where > initialState = S 0 0 > runOne = runningAverage but how would i use this, e.g. > --summarizeMany vs = last $ evalState (mapM runOne vs) initialState is not possible as it has an ambiguous type. 1) what am i doing wrong? what are the right type class and instance declarations? 2) is there a better way of expressing this kind of "on-line" calculation, perhaps in pure (non-monadic) functions? i tried mapAccumL, but was looking for something a little cleaner. best, ben

2 1