- Haskell-Cafe - Haskell.org

Lazy producing a list in the strict ST monad
by Nicu Ionita 19 Jun '12

19 Jun '12

Hi, I'm trying to produce a list in the strict ST monad. The documentation of ST says that the monad is strict in the state, but not in the values. So I expect that, when returning a list, I get back only the Cons (with 2 unevaluated thunks). Now, when I need the first element (head), this will be evaluated (with whatever actions are necessary in the ST universe) and the tail is again a Cons with unevaluated parts. Internally my list is stored in a vector, and the elements are generated phasewise, each phase generating 0 or more elements in the vector, and a fuction splitMove is driving this process (see code below). I would expect that the first phase triggers, generates some moves, then (after these are consumed from the list) the next phase triggers generating the next few moves and so on. But when I trace the phases (Debug.Trace.trace) I get all the trace messages in front of the first move: Moves for fen: rnbqkbnr/pp3ppp/4p3/2pp4/3P4/2NQ4/PPP1PPPP/R1B1KBNR w After move generation... 0 >= 0 : next phase 3 >= 3 : next phase 3 >= 3 : next phase 42 >= 42 : next phase 44 >= 44 : next phase d4c5 g1f3 g1h3 c3b1 ... This seems not to be just an unhappy combination between trace and ST, as also the program without trace is beeing slower than the same implemented with plain lists, which is hard to believe (in many cases the move list is not consumed to the end). I wonder if my expectation is wrong, but I don't find a way to do this. Here is the (incomplete) code: produceList ... = runST $ do ml <- newMList ... listMoves ml -- Transforms a move list to a list of moves - lazy listMoves :: MList s -> ST s [Move] listMoves ml = do sm <- splitMove ml case sm of Just (m, ml') -> do rest <- listMoves ml' return $ m : rest Nothing -> return [] -- Split the first move from the move list and return it together with -- the new move list (without the first move). Return Nothing if there -- is no further move splitMove :: MList s -> ST s (Maybe (Move, MList s)) splitMove ml | mlToMove ml >= mlToGen ml = do mml <- trace trm $ nextPhase ml case mml of Nothing -> return Nothing Just ml' -> splitMove ml' | otherwise = do m <- U.unsafeRead (mlVec ml) (mlToMove ml) case mlCheck ml ml m of Ok -> return $ Just (m, ml1) Skip -> splitMove ml1 Delay -> splitMove ml1 { mlBads = m : mlBads ml } where ml1 = ml { mlToMove = mlToMove ml + 1 } trm = show (mlToMove ml) ++ " >= " ++ show (mlToGen ml) ++ " : next phase"

2 1

Re: [Haskell-cafe] [Haskell-beginners] Function application versus function composition performance
by KC 19 Jun '12

19 Jun '12

A good functional programming language has a good "code algebra" after parsing to which algebraic transformations can be applied for optimization. For example, reducing the need for generating intermediate data structures. See: fusion. On Tue, Jun 19, 2012 at 3:01 PM, Matt Ford <matt(a)dancingfrog.co.uk> wrote: > Hi All, > > My last question got me thinking (always dangerous): an expression > that doubles a list and takes the 2nd element (index 1), I assume, > goes through the following steps. > > double (double [1,2,3,4]) !! 1 > double ( 1*2 : double [2,3,4]) !! 1 > 1*2*2 : double ( double [2,3,4] ) !! 1 > 1*2*2 : double ( 2*2 : double [3,4] ) !! 1 > 1*2*2 : 2*2*2 : double ( double [3,4] ) !! 1 > 2*2*2 > 8 > > Up until the element requested all the proceeding elements have to > have the expression formed as Haskell process the calculation. > > Now, I want to compare this to using function composition > > ( double . double ) [ 1 ,2, 3, 4 ] !! 1 > > This is the bit I'm unsure of - what does the composition look like. > It is easy to see that it could be simplified to something like: > > ( double . double) (x:xs) = x*4 : (double . double) xs > > This would mean the steps could be written > > (double . double) [ 1,2,3,4 ] !! 1 > (1*4 : (double.double) [2,3,4]) !! 1 > (1*4 : 2*4 : (double.double) [ 3,4 ]) !! 1 > 2*4 > 8 > > Ignoring the start and end steps, it will be half the number of steps > compared to the application version. Significant then, over long > lists. > > So is this true, are composite functions simplified in Haskell in > general so that they may have improved performance over function > application? > > I've seen posts on the internet that say it's a matter of style only: > > http://stackoverflow.com/questions/3030675/haskell-function-composition-and… > . > But my reasoning suggests it could be more than that. > > Perhaps, function application is similarly optimised - maybe by > replacing all functions applications with composition and then > simplifying? Or maybe the simplifying/optimisation step never > happens? As you can see I'm just guessing at things :-) But it's > nice to wonder. > > Many thanks for any pointers, > > Matt. > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -- -- Regards, KC

1 0

Haskell Implementors' Workshop 2012, Second CFT
by Johan Tibell 19 Jun '12

19 Jun '12

Call for Talks ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2012 Copenhagen, Denmark, September 14th, 2012 The workshop will be held in conjunction with ICFP 2012 http://www.icfpconference.org/icfp2012/ Important dates Proposal Deadline: 10th July 2012 Notification: 27th July 2012 Workshop: 14th September 2012 The Haskell Implementors' Workshop is to be held alongside ICFP 2012 this year in Copenhagen, Denmark. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This relatively new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2012. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for a relatively short talk. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 200 words to: johan.tibell(a)gmail.com We will also have a lightning talks session which will be organised on the day. These talks will be 2-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Lennart Augustsson (Standard Chartered Bank) * Manuel M T Chakravarty (University of New South Wales) * Gregory Collins - co-chair (Google) * Simon Marlow (Microsoft Research) * David Terei (Stanford University) * Johan Tibell - co-chair (Google)

1 0

Call for Papers: STVR Special Issue on Tests and Proofs
by Achim D. Brucker 19 Jun '12

19 Jun '12

Apologies for duplicates. CALL FOR PAPERS STVR Special Issue on Tests and Proofs http://lifc.univ-fcomte.fr/tap2012/stvr/ The Software Testing, Verification & Reliability (STVR) journal (http://www3.interscience.wiley.com/journal/13635/home) invites authors to submit papers to a Special Issue on Tests and Proofs. Background ========== The increasing use of software and the growing system complexity make focused software testing a challenging task. Recent years have seen an increasing industrial and academic interest in the use of static and dynamic analysis techniques together. Success has been reported combining different test techniques such as model-based testing, structural testing, or concolic testing with static techniques such as program slicing, dependencies analysis, model-checking, abstract interpretation, predicate abstraction, or verification. This special issue serves as a platform for researchers and practitioners to present theory, results, experience and advances in Tests and Proofs (TAP). Topics ====== This special issue focuses on all topics relevant to TAP. In particular, the topics of interest include, but are not limited to: * Program proving with the aid of testing techniques * New challenges in automated reasoning emerging from specificities of test generation * Verification and testing techniques combining proofs and tests * Generation of test data, oracles, or preambles by deductive techniques such as: theorem proving, model checking, symbolic execution, constraint logic programming, SAT and SMT solving * Model-based testing and verification * Automatic bug finding * Debugging of programs combining static and dynamic analysis * Transfer of concepts from testing to proving (e.g., coverage criteria) and from proving to testing * Formal frameworks for test and proof * Tool descriptions, experience reports and evaluation of test and proof * Case studies combining tests and proofs * Applying combination of test and proof techniques to new application domains such as validating security procotols or vulnerability detection of programs * The processes, techniques, and tools that support test and proof Submission Information ====================== The deadline for submissions is 17th December, 2012. Notification of decisions will be given by April 15th, 2013. All submissions must contain original unpublished work not being considered for publication elsewhere. Original extensions to conference papers - identifing clearly additional contributions - are also encouraged unless prohibited by copyright. Submissions will be refereed according to standard procedures for Software Testing, Verification and Reliability. Please submit your paper electronically using the Software Testing, Verification & Reliability manuscript submission site. Select "Special Issue Paper" and enter "Tests and Proofs" as title. Important Dates: ================ * Paper submission: December 17, 2012 * Notification: April 15, 2013 Guest Editors ============= * Achim D. Brucker, SAP Research, Germany http://www.brucker.ch/ * Wolfgang Grieskamp, Google, U.S.A. http://www.linkedin.com/in/wgrieskamp * Jacques Julliand, University of Franche-Comté, France http://lifc.univ-fcomte.fr/page_personnelle/accueil/8 -- Dr. Achim D. Brucker, SAP Research, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch

1 0

How do people still not understand what FP is about? What are we doing wrong?
by Ben Kolera 18 Jun '12

18 Jun '12

Saw this float by in twitter, and it made me a bit sad. Obviously this is still a large misunderstanding of FP in the larger programming community and it make me wonder what we FP enthusiasts are doing wrong to not get the message out to people. "Programming languages that require random senseless voodoo to get an effect are awesome. Let's make programming hard through poor design." [1] The sad thing about this is that the inverse of this has more truth to it; that "languages that allow people to intersperse side effects anywhere in their computation without thought are flawed by design and allow programmers to do stupid things that hinder the composability, thread safety and ability to reason of/about their code". Has anyone had any experience / success with convincing people that the "senseless voodoo" is actually a boon rather than a bane? Is it even worth trying to convince people so set in their ways? ( Sorry if this is even too off-topic for the cafe. Just needed a place to vent my frustration at this. ) Cheers, Ben [1] https://twitter.com/cwestin63/status/214793627170390018

9 10

Re: [Haskell-cafe] [Haskell] ANNOUNCE: set-monad
by George Giorgidze 18 Jun '12

18 Jun '12

Hi Derek, On 16 June 2012 21:53, Derek Elkins <derek.a.elkins(a)gmail.com> wrote: > The law that ends up failing is toList . > fromList /= id, i.e. fmap g . toList . fromList . fmap h /= fmap g . > fmap h This is not related to functor laws. The property that you desire is about toList and fromList. The toList and fromList functions are not required to satisfy toList . fromList /= id. This does not hold for Data.Set and it does not hold for the Data.Set.Monad wrapper either. Duplicates are lost when lists are converted into sets. Other instances of fromList and toList also fail to satisfy the property that you desire (e.g., Map). Cheers, George

1 0

Re: [Haskell-cafe] Haskell (GHC 7) on ARM
by Ben Gamari 18 Jun '12

18 Jun '12

Joshua Poehls <joshua(a)poehls.me> writes: > Hello Ben, > Hello, Sorry for the latency. I'm currently on vacation in Germany so I haven't had terribly consistent Internet access. I've Cc'd haskell-cafe@ as I've been meaning to document my experiences anyways and your email seems like a good excuse to do this. > I just got a Raspberry Pi and I'm interested in running Haskell on it. So > far I'm running Arch Linux ARM and I noticed there is is a GHC package > available, but it is version 6.12.3. > > Doing research online I saw that you did some work on adding GHCi support > for ARM in GHC 7.4. I was wondering if you had anything to share related to > running GHC/GHCI 7.4 on ARM, specifically Arch Linux ARM. > Indeed my ARM linker patch was merged into GHC 7.4.2. This means that ARM is now a fully supported target platform for GHC, complete with GHCi support (which is pretty much necessary for many ubuiquitous packages). My ARM development environment consists of a PandaBoard (and before this a BeagleBoard) running Linaro's Ubuntu distribution. For this reason, I'm afraid I won't be of terribly much help in the case of Arch. That being said, GHC has a wonderful build system which has never given me trouble (except in cases of my own stupidity). Just installing the required development packages and following the build instructions on Wiki[1] is generally quite sufficient. I've also have some notes of my own[2] where I've collected my own experiences. As you likely know, GHC doesn't have a native ARM code generator of its own, instead relying on LLVM for low-level code generation. For this reason, you'll first need to have a working LLVM build. I have found that the ARM backend in the 3.0 release is a bit buggy and therefore generally pull directly from git (HEAD on my development box is currently sitting at 7750ff1e3cbb which seems to be stable). That being said, I haven't done much work in this space recently and it's quite likely that the 3.1 release is better in this respect. Compiling LLVM is one case where I have found the limited memory of my BeagleBoard (which is I believe is similar to the Raspberry Pi) to be quite troublesome. There are cases during linking where over a gigabyte of memory is necessary. At this stage the machine can sit for hours thrashing against its poor SD card making little progress. For this reason, I would strongly recommend that you cross-compile LLVM. The process is pretty straightforward and I have collected some notes on the matter[3]. The size of GHC means that in principle one would prefer to cross-compile. Unfortunately, support[4] for this is very new (and perhaps not even working/complete[5]?) so we have to make due with what we have. The build process itself is quite simple. You will want to be very careful to ensure that the ghc/libraries/ trees are sitting on the same branch as your ghc/ tree (with the ghc/sync-all script). Inconsistency here can lead to very ambiguous build failures. Otherwise, the build is nearly foolproof (insofar as this word can describe any build process). The build takes the better part of a day on my dual-core Pandaboard. I can't recall what the maximum memory consumption was but I think it might fit in 512MB. Lastly, if I recall correctly, you will find that you'll need to first build GHC 7.0 bootstrapped from 6.12 before you can build 7.4 (which requires a fairly new stage 0 GHC). Let the list know if you encounter any issues. I'll try to dust off my own development environment once I get back to the states next week to ensure that everything still works. I've been meaning to setup the PandaBoard as a build slave as Karel's has been failing for some time now (perhaps you could look into this, Karel?). Moreover, perhaps I can find a way to produce redistributable binaries to help others get started. Cheers, - Ben [1] http://hackage.haskell.org/trac/ghc/wiki/Building [2] http://bgamari.github.com/posts/ghc-llvm-arm.html [3] http://bgamari.github.com/posts/cross-compiling_llvm.html [4] http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation [5] http://www.haskell.org/pipermail/cvs-ghc/2012-February/070791.html

4 4

Single board computers on HaskellWiki
by Henk-Jan van Tuyl 18 Jun '12

18 Jun '12

L.S., As more and more people start to develop software in Haskell for single board computers, I created the HaskellWiki pages Arduino[0], ARM[1], Raspberry Pi[2], BeagleBoard[3] and PandaBoard[4]. I hope experts on the matter will give these pages more body (for example, describe what is necessary to get Haskell programs running on these platforms) and add links to relevant web pages. The PandaBoard page needs an image, I couldn't find one with public domain license. If you don't know how to edit HaskellWiki pages, read the contribute page[5] first. To get your appetite wet, if you are not involved in this yet, take a look at the Arduino Weather Clock[6]; this is really a fun project. Regards, Henk-Jan van Tuyl [0] http://www.haskell.org/haskellwiki/Arduino [1] http://www.haskell.org/haskellwiki/ARM [2] http://www.haskell.org/haskellwiki/Raspberry_Pi [3] http://www.haskell.org/haskellwiki/BeagleBoard [4] http://www.haskell.org/haskellwiki/PandaBoard [5] http://www.haskell.org/haskellwiki/HaskellWiki:Contributing [6] http://www.geeky-gadgets.com/arduino-weather-clock-13-01-2010/ -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

Receiving UDP messages on Windows 7
by Edward Amsden 18 Jun '12

18 Jun '12

Hi all, I have the following program, which I'm running using runghc 7.4.1 with HP2012.2 on Windows 7: == {-# LANGUAGE OverloadedStrings #-} module Main where import Network.Socket hiding (send, sendTo, recv, recvFrom) import Network.Socket.ByteString import qualified Data.Text as T import qualified Data.Text.Encoding as T import qualified Data.Text.IO as T port :: String port = show (5555 :: Int) main :: IO () main = withSocketsDo $ do addrInf:_ <- fmap (filter ((== AF_INET) . addrFamily)) $ getAddrInfo (Just (defaultHints {addrFlags = [AI_PASSIVE]})) Nothing (Just port) putStrLn "Address info: " print addrInf sock <- socket (addrFamily addrInf) Datagram defaultProtocol putStrLn "Socket created" bindSocket sock (addrAddress addrInf) putStrLn "Socket bound" let procMessages = do (msg, addr) <- recvFrom sock 1024 let addrTxt = T.pack $ show addr msgTxt = T.decodeUtf8 msg outputTxt = T.concat [addrTxt, " says ", msgTxt] T.putStrLn outputTxt procMessages procMessages == I'm trying to receive incoming UDP packets on port 5555. Unfortunately, when I run the program it does not receive packets. It prints the address info, and the messages that the socket has been created and bound. When I run Wireshark I can see that there are indeed incoming UDP packets arriving on port 5555 (from another computer on the local network running a proprietary program). The other bit of information that may be useful is that the machine has 2 network interfaces. However, when I replace the Nothing parameter of getAddrInfo with (Just "192.168.1.3") which is the address of the correct NIC, the behavior is as before. Is there something I'm missing?

2 2

Noticed this change about infix decls in GHC 7.4.2
by Christopher Done 18 Jun '12

18 Jun '12

So I have some module, in a work project that I'm portnig from GHC 6.12.3 to GHC 7.4.2, module Data.Monoid.Operator where import Data.Monoid (++) :: Monoid a => a -> a -> a (++) = mappend infixr 5 ++ This compiles happily on GHC 6.12.3, but on 7.4.2 says: src/Data/Monoid/Operator.hs:9:10: Ambiguous occurrence `++' It could refer to either `Data.Monoid.Operator.++', defined at src/Data/Monoid/Operator.hs:8:1 or `Prelude.++', imported from `Prelude' at src/Data/Monoid/Operator.hs:3:8-27 (and originally defined in `GHC.Base') It seems that it used to assign higher priority to the declared thing in the current module over the imported one. Is this intentional? I'd suspect not, given that if I comment the binding out: -- (++) :: Monoid a => a -> a -> a -- (++) = mappend I get: src/Data/Monoid/Operator.hs:9:10: The fixity signature for `++' lacks an accompanying binding (The fixity signature must be given where `++' is declared) Which seems to contradict the previous error message. Bug? Ciao! P.S. Yes, I know I can fix this by not importing Prelude. P.P.S Yes, I know there's a <> or <+> defined now, but I prefer (++), thanks.

2 1