October 2010 - Haskell-Cafe

ANN: fountain-0.0.0
by Tom Hawkins 20 Oct '10

20 Oct '10

This library [1] implements a fountain code [2]. Fountain codes are forward error correction codes for erasure channels [3]. A fountain code encodes a message into an infinite stream of packets -- transmitters generate message packets at random, on-the-fly. To reconstruct the message, receivers simply need to capture enough packets for the decoding process. As a rateless code, fountain codes automatically adapt to varying channel conditions. Some of the more interesting applications of fountain codes include unsynchronized data broadcast and distributed download. For example, a multiple number of devices can transmitting content to multiple receivers without any coordination. Because packets are generated at random, receivers increase their bandwidth simply by listening to more transmitters. Note that receivers can also start generating packets and forwarding the message on even before they have decoded the complete message. This library provides a packet generator and a decoder for one of the first known fountain codes: LT codes [4]. It also includes a test function to experiment with message lengths, and encoding degrees -- it runs a simulation to determine the number of packets needed to decode a message. -Tom [1] http://hackage.haskell.org/package/fountain [2] http://en.wikipedia.org/wiki/Fountain_code [3] http://en.wikipedia.org/wiki/Binary_erasure_channel [4] http://en.wikipedia.org/wiki/LT_codes

2 2

Getting results of of runSTUArray
by Henry Laxen 20 Oct '10

20 Oct '10

1{- Dear Group, I am trying to do something that I think should be very simple, but I just can't seem to figure out how. The idea is that I want to use runSTUArray to build up an array, but I want to look at the array after each iteration and possiblely accumulate some elements. -} import Debug.Trace import Control.Monad import Control.Monad.ST import Data.Array.ST incArray arr index = do x <- readArray arr index writeArray arr index (x+1) checkArray = filter (\(i,e) -> e == 1) run = runSTUArray ( do a <- newArray (0,9) 0 :: ST s (STUArray s Int Int) all <- forM [1..10] (\i -> do let j = i `mod` 4 incArray a j b <- getAssocs a -- now run something like checkArray and build up a list of "wanted" elements -- which I would like to return from run, but I don't see how return b) -- Or, if I cound run (lazily) on "all" (the result of the forM) -- I could do my accumulation let theAnswerIWant = concatMap checkArray all return (trace (show theAnswerIWant) a)) -- I can't seem to return anything but a here {- result is: array [(1,1),(1,1),(2,1),(1,1),(2,1),(3,1),(0,1), (1,1),(2,1),(3,1),(0,1),(2,1),(3,1),(0,1),(3,1), (0,1)] (0,9) [(0,2),(1,3),(2,3),(3,2),(4,0),(5,0),(6,0),(7,0),(8,0),(9,0)] is there any way to get theAnswerIWant out of run? Thanks in advance for any insights. -}

2 1

Idea for a tool
by Michael Snoyman 20 Oct '10

20 Oct '10

Hi all, I saw a quote from Eric Kow via Neil Mitchell[1] that we don't spend enough time writing tools. Well, I've decided that the most annoying part of package maintainership right now is staying on top of new versions of dependencies. We essentially have two options right now: * Follow the PVP and put an upper bound on all dependencies, and people will be upset when your package only works with the old version of the dependency. * Skip the upper bound, and risk having your code break when there's a new version. I have an idea for a tool: you give it a list of packages you maintain, or even better yet, you give it your email address and it gets that list automatically. Then is looks through all your dependencies and sees if you have any upper bounds preventing newer versions from being used. Bonus points for making it a web service that just gives you an RSS feed. If anyone's interested in writing a tool like that, let me know. Otherwise, next time I'm twiddling my thumbs I'll try to throw it together. I've never dealt directly with the Cabal library, but there's a first time for everything. If someone else wants to write that tool and wants help sticking a web service on it, let me know. Michael [1] http://neilmitchell.blogspot.com/2010/10/enhanced-cabal-sdist.html

3 4

Re: [Haskell-cafe] Haskellers.com skills list moderation?
by John Lato 20 Oct '10

20 Oct '10

My $.02 follows: > From: Michael Snoyman <michael(a)snoyman.com> > > There's only two skills which I think absolutely must go: > > Other languages I know: C# .NET, XSLT, Microsoft SQL Server, XML, SQL, > CSS, C, C++, Java, HTML, Visual Basic Script, Pascal, Rexx, Basic and > assembler > tool building > Agreed that both should go. > There are 11 skills I'm leaning towards dropping, all because they > fall in the too vague/too general category. Your input is requested on > these. They are: > > Attribute Grammar > Keep as "Attribute Grammars" > Cabal, packaging, build and distribution tools > This should be two categories: "Cabal internals" and "Software packaging/distribution tools". Keep Cabal internals, possibly keep the other > Categorical Programming Denotational design > Digital Forensics > keep > Fault Tolerant Server Software Mathematics > drop (possibly keep FTSS, maybe change the name) > Programming using Arrows > Possibly keep with a different name > Proving observational equivalence between Haskell programs drop > Transactional business applications development > I'm not entirely sure what this means, specifically if it's business transactions or db/software transactions. > UNIX Scripting and Tool Authoring > keep as "UNIX Scripting" > > Of the remaining 32 skills, some of them fall in the "too specific" > range just a bit (software transactional memory, property based > testing), but I'm inclined to let it slide. These 32 are: > > Advanced type-level programming (GADTs, TypeFamilies, proofs, etc.) > Algorithmic Problem Solving > Bioinformatics > Concurrent Haskell > DSL Design > Darcs internals > Foreign Function Interface (FFI) > Formal Verification > Functional graphics programming (2D, 3D, GPU) > GHC internals > Generic Programming > Graphical User Interfaces > Happstack Web Framework > Hardware Acceleration DSLs > Haskell on embedded devices > High Assurance Software Development > High-performance Haskell > Metaprogamming via Template Haskell > Natural Language Processing (tagging, parsing, translation,...) > Physics & Simulation > Programming language translation > Property based testing (QuickCheck) > Purely functional data structures — design and implementation > Reverse Engineering > Robotics and Automation > Signal Processing > Software Transactional Memory > Teaching Haskell > Web development (HTML, CSS and Javascript) > Yesod Web Framework > I would argue for keeping most of these. I do think that skills based on specific packages (Happstack, Yesod, STM?) perhaps should be dropped, except for packages that are integral to the Haskell universe (compilers, Cabal, Darcs?, QuickCheck?). For these packages, I think the "-internals" categories are the most useful. What about rolling Happstack, Yesod, etc. into "Haskell Web Frameworks", and possibly also keeping the "Web Development (HTML, CSS and Javascript)" category? John

4 5

Why isn't there a cheaper "split-in-two" operation for Data.Set?
by Ryan Newton 20 Oct '10

20 Oct '10

Would there be anything wrong with a Data.Set simply chopping off half its (balanced) tree and returning two approximately balanced partitions -- i.e. Data.Set.split without the pivot argument? Even though it can't quite be constant-time (still need rebalancing) it could still be cheaper than Data.Set.split, right? In the context of Set.hs, I'm thinking along the lines of something like the following: cleave :: Set a -> (Set a, Set a) cleave Tip = (Tip, Tip) cleave (Bin _ x l r) | size l > size r = (l, insertMin x r) | otherwise = (insertMax x l, r) For one thing, this seems like the proposed function would be useful for consuming a set in parallel, similar to Guy Steele's arguments in recent talks (see Organizing Functional Code for Parallel Execution; or, foldl and foldr Considered Slightly Harmful<http://research.sun.com/projects/plrg/Publications/ICFPAugust2009Steele.pdf>). That is, one splits a tree and uses "par" to process the left and right half in parallel, enabling Alternatively, it would be simple to provide a parallel version of mapMonotonic that does this internally, i.e.: mapMonotonic _ Tip = Tip mapMonotonic f (Bin sz x l r) = Bin sz (f x) (mapMonotonic f l) (mapMonotonic f r) Becomes something like: parMapMonotonic f (Bin sz x l r) = par left $ seq right $ Bin sz (f x) left right where left = mapMonotonic f l right = mapMonotonic f r Cheers, -Ryan

5 5

HDBC/ODBC/MySQL - working configuration?
by Neil Davies 20 Oct '10

20 Oct '10

Hi I'm having some difficulty getting the above combination to work, I've successfully used ODBC against MS but the MySQL stuff is creating some really interesting error conditions in the HDBC-ODBC module. My first thought is that it must be me, so does anyone out there have this combination working (with or without HaskellDB)? If so, can you tell me which versions of things you are using and which ODBC drivers (and configurations) you are using? Cheers Neil

1 0

HaskellDB/ODBC/MySQL issue
by Neil Davies 19 Oct '10

19 Oct '10

Hi I can't seem to get the combination of HaskellDB/ODBC/MySQL to even get off the ground, example: import OmlqDBConnectData (connect'options) import Database.HaskellDB import Database.HaskellDB.HDBC.ODBC (odbcConnect) import Database.HaskellDB.Sql.MySQL (generator) main = odbcConnect generator connect'options $ \db -> tables db >>= print gives me Prelude.(!!): index too large Suggestions? Cheers Neil

2 1

Happstack, RqData: (How) can I extract multiple data from form?
by Никитин Лев 19 Oct '10

19 Oct '10

-------- Пересылаемое сообщение -------- 20.10.10, 00:22, "Никитин Лев" <leon.v.nikitin(a)pravmail.ru>: >>Are formlets integrated with HSP? > hsp support is in a separate package: > http://hackage.haskell.org/package/formlets-hsp > There is a demo of using HSP+Formlets+Happstack here: > http://src.seereason.com/formlets-hsp/examples/happs-hsp/ > hope this helps! > - jeremy > Thanks! (Sorry for my stuped question) -------- Завершение пересылаемого сообщения --------

1 0

Template Haskell: onward and upward
by Simon Peyton-Jones 19 Oct '10

19 Oct '10

Folks Following lots of feedback from users, especially at ICFP, I've evolved some proposals for Template Haskell, that should make it both more expressive, and more secure. http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal Do let me know what you think. Discussion by email is fine (cc me if it's on Haskell-cafe), or comments direct on the Trac. (None of this will be in GHC 7.0; it's a proposed plan for post-release improvements.) Thanks Simon

3 2

An interesting paper from Google
by Andrew Coppin 19 Oct '10

19 Oct '10

http://k1024.org/~iusty/papers/icfp10-haskell-reagent.pdf I'm sure some of you have seen this already. For those who lack the time or inclination to read through the (six) pages of this report, here's the summary... We [i.e., the report authors] took a production Python system and rewrote bits of it in Haskell, some of which is now in production use. We conclude the following: - Python lets you just do whatever the hell you want, but Haskell demands that you actually have a *plan* before you start churning out code and running it. The result is generally cleaner and more consistent when you get there. - Haskell's much-criticised immutable data is actually an *advantage* for backtracking search problems. - Haskell wins for thread-safety. - ADTs are nicer than exceptions. - The parts of Haskell stolen by Python aren't as nice in Python as they are in Haskell. [Well, duh.] - We like what GHC provides for profiling. - We are dissappointed by what GHC provides for debugging. - "String" is too slow. None of the alternatives seem to be widely supported. If your library consumes Strings and returns Strings, the fact that ByteString exists doesn't help you. - Recent changes to GHC broke our code. (Specifically, extensible exceptions.) We were quite surprised that such a "stable" and "mature" system as GHC would do this to us. - Haskell has quite a high barrier to entry. [Again, duh.] The paper also contains an interesting section that basically says "we tried porting the Python implementing of XYZ into Haskell, but there wasn't really any advantage because it's all I/O". In my humble opinion, "it's all I/O" is a common beginner's mistake. Reading between the lines, it sounds like they wrote the whole thing in the IO monad, and then decided it looked just like the existing Python code so there wasn't much point in continuing. I guess it's one of the bad habits that imperative programmers get into. With a little more experience, you eventually figure out that you can limit the stuff actually in the IO monad to a surprisingly small section, and so almost everything else in pure code, no matter how much the problem looks like it's "all I/O". But anyway, I'm only guessing from what I can actually see with my own eyes in the report itself. I'm surprised about the profiler. They seem really, really impressed with it. Which is interesting to me, since I can never seen to get anything sensible out of it. It always seems to claim that my program is spending 80% of its runtime executing zipWith or something equally absurd. I'm unsurprised which their dissappointment with debugging. I'm still quite surprised that there's no tool anywhere which will trivially print out the reduction sequence for executing an expression. You'd think this would be laughably easy, and yet nobody has done it yet. Their comments about String are sadly true.

8 11