- Haskell-Cafe - Haskell.org

happstack file serving
by Antoine Latter 02 Nov '11

02 Nov '11

Including list. ---------- Forwarded message ---------- From: Antoine Latter <aslatter(a)gmail.com> Date: Tue, Nov 1, 2011 at 11:33 AM Subject: Re: [Haskell-cafe] happstack file serving To: Gary Klindt <gary.klindt(a)googlemail.com> On Tue, Nov 1, 2011 at 11:24 AM, Gary Klindt <gary.klindt(a)googlemail.com> wrote: > Hey Antoine, > > thank you for answering. Your strategy is quite similar to the one I prefer. > I misunderstood the behaviour of serveDirectory. The problem with external > javascript files is solved. > The other problem I had, was, that the argument 'msum' is a list, which has > elements with the same type, so I needed a conversion from > m [Char] to m Response. > In Happstack.Server.Response there is a function, which actually does that: > flatten: > > module Main where > > import Happstack.Server > import Control.Monad > > main :: IO () > main = simpleHTTP nullConf $ > msum [ flatten $ dir "ok" $ ok "jeahh!" > , serveDirectory DisableBrowsing ["index.html"] "static" ] > I would likely write that particular example: > dir "ok" $ ok $ toResponse "jeahh!" I find it convenient to convert to a 'Response' as close to the 'bottom' of the stack as possible. Antoine

1 0

LDTA 2012: Call for Papers
by Anya Helene Bagge 01 Nov '11

01 Nov '11

LDTA 2012 Call for Papers 12th International Workshop on Language Descriptions, Tools, and Applications www.ldta.info Tallinn, Estonia March 31 & April 1, 2012 an ETAPS workshop LDTA is an application and tool-oriented workshop focused on grammarware - software based on grammars in some form. Grammarware applications are typically language processing applications and traditional examples include parsers, program analyzers, optimizers and translators. A primary focus of LDTA is grammarware that is generated from high-level grammar-centric specifications and thus submissions on parser generation, attribute grammar systems, term/graph rewriting systems, and other grammar-related meta-programming tools, techniques, and formalisms are encouraged. LDTA is also a forum in which theory is put to the test, in many cases on real-world software engineering challenges. Thus, LDTA also solicits papers on the application of grammarware to areas including, but not limited to, the following: - program analysis, transformation, generation, and verification, - implementation of Domain-Specific Languages, - reverse engineering and re-engineering, - refactoring and other source-to-source transformations, - language definition and language prototyping, and - debugging, profiling, IDE support, and testing. Note that LDTA is a well-established workshop similar to other conferences on (programming) language engineering topics such as SLE and GPCE, but is solely focused on grammarware. Paper Submission ---------------- LDTA solicits papers in the following categories. - research papers: original research results within the scope of LDTA with a clear motivation, description, analysis, and evaluation. - short research papers: new innovative ideas that have not been completely fleshed out. As a workshop, LDTA strongly encourages these types of submissions. - experience report papers: description of the use of a grammarware tool or technique to solve a non-trivial applied problem with an emphasis on the advantages and disadvantages of the chosen approach to the problem. - tool demo papers: discussion of a tool or technique that explains the contributions of the tool and what specifically will be demonstrated. Each submission must clearly state in which of these categories it falls, and must not be published or submitted elsewhere. Papers are to use the standard LaTeX article style and the authblk style for affiliations; a sample of which is provided at www.ldta.info. Research and experience papers are limited to 15 pages, tool demonstration papers are limited to 10 pages, and short papers are limited to 6 pages. The final version of the accepted papers will, pending approval, be published in the ACM Digital Library and will also be made available during the workshop. Please submit your abstract and paper using EasyChair at http://www.easychair.org/conferences/?conf=ldta2012. The authors of each submission are required to give a presentation at LDTA 2011 and tool demonstration paper presentations are intended to include a significant live, interactive demonstration. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, assuming acceptance, be published in journal form. As in past years this will be done in a special issue of the journal Science of Computer Programming (Elsevier Science). Invited Speaker --------------- To be announced Important Dates --------------- Abstract submission: Nov. 28, 2011 Full paper submission: Dec. 5, 2011 Author notification: Jan. 20, 2012 Camera-ready papers: Feb. 05, 2012 LDTA Workshop: Mar. 31 - Apr. 1, 2012 LDTA Tool Challenge ------------------- The 2011 Workshop pioneered the LDTA Tool Challenge where tool developers were invited to develop solutions to a range of language processing tasks over a simple but evolving set of imperative programming languages. We expect a challenge to form part of LDTA every two years. The 2012 workshop will feature presentations devoted to a de-brief of the 2011 challenge, based on the paper currently being prepared by challenge participants. Program Committee ----------------- Suzana Andova, Eindhoven University of Technology, The Netherlands (co-chair) Anya Helene Bagge, University of Bergen, Norway Kyung-Goo Doh, Hanyang University, Ansan, South Korea Jeff Gray, University of Alabama, USA Görel Hedin, Lund Institute of Technology, Sweden Zoltán Horváth, Eötvös Loránd University, Budapest, Hungary Zhenjiang Hu, National Institute of Informatics, Japan Roberto Ierusalimschy, Pontifícia Universidade Católica do Rio de Janeiro, Brazil Ivan Kurtev, University of Twente, The Netherlands Marjan Mernik, University of Maribor, Slovenia Nate Nystrom, University of Lugano, Switzerland João Saraiva, Universidade do Minho, Braga, Portuga Sylvain Schmitz, Ecole Normale Supérieure de Cachan, France Anthony Sloane, Macquarie University, Australia (co-chair) Robert Tairas, Inria, France Laurence Tratt, King's College London, UK Vadim Zaytsev, Centre for Mathematics & Computer Science, The Netherlands Organizing Committee -------------------- Anya Helene Bagge, University of Bergen, Norway Emilie Balland, INRIA, France Steering Committee ------------------ Mark van den Brand, Eindhoven University of Technology, The Netherlands Görel Hedin, Lund University, Sweden Tony Sloane, Macquarie University, Australia Eric Van Wyk, University of Minnesota, United States

1 0

Organizing big repository
by Konstantin Litvinenko 01 Nov '11

01 Nov '11

I am trying to understand how to organize my code and edit-compile-run cycles. I can't figure out how to setup environment in such why that when I build some program using cabal, cabal will rebuild program dependencies if some was changed. I don't want to configure/build/install manually. Having program 'foo' depends on lib 'bar' I want to edit some files in 'bar' than build 'foo' and get 'bar' rebuilt and 'foo' rebuilt/relink. How can I do this?

5 5

lazy A-star search
by Anton Kholomiov 01 Nov '11

01 Nov '11

Recently I was looking for an A-star search algorithm. I've found a package but I couldn't understand the code. Then I saw some blogposts but they were difficult to understand too. I thought about some easier solution that relies on laziness. And I've come to this: Heuristic search is like depth-first search but solutions in sub-trees are concatenated with mergeBy function, that concatenates two list by specific order: module Search where import Control.Applicative import Data.Function(on) import Control.Arrow(second) import Data.Tree -- | Heuristic search. Nodes are visited from smaller to greater. searchBy :: (a -> a -> Ordering) -> Tree a -> [a] searchBy heur (Node v ts) = v : foldr (mergeBy heur) [] (searchBy heur <$> ts) -- | Merge two lists. Elements concatenated in specified order. mergeBy :: (a -> a -> Ordering) -> [a] -> [a] -> [a] mergeBy _ a [] = a mergeBy _ [] b = b mergeBy p (a:as) (b:bs) | a `p` b == LT = a : mergeBy p as (b:bs) | otherwise = b : mergeBy p bs (a:as) Now we can define specific heuristic search in terms of searchBy: -- | Heuristic is distance to goal. bestFirst :: Ord h => (a -> h) -> (a -> [a]) -> a -> [a] bestFirst dist alts = searchBy (compare `on` dist) . unfoldTree (\a -> (a, alts a)) -- | A-star search. -- Heuristic is estimated length of whole path. astar :: (Ord h, Num h) => (a -> h) -> (a -> [(a, h)]) -> a -> [a] astar dist alts s0 = fmap fst $ searchBy (compare `on` astarDist) $ unfoldTree gen (s0, 0) where astarDist (a, d) = dist a + d gen (a, d) = d `seq` ((a, d), second (+d) <$> alts a) I'm wondering is it effective enough? Anton

5 9

ANN: Monad.Reader Issue 19
by Brent Yorgey 01 Nov '11

01 Nov '11

I am pleased to announce that Issue 19 of The Monad.Reader, a special issue on parallelism and concurrency, is now available: http://themonadreader.files.wordpress.com/2011/10/issue19.pdf Issue 19 consists of the following three articles: * Mighttpd – a High Performance Web Server in Haskell by Kazu Yamamoto * High Performance Haskell with MPI by Bernie Pope and Dmitry Astapov * Coroutine Pipelines by Mario Blažević Feel free to browse the source files. You can check out the entire repository using darcs: darcs get http://code.haskell.org/~byorgey/TMR/Issue19 If you’d like to write something for Issue 20, please get in touch. The deadline will likely be in December; more details will be forthcoming.

4 3

Re: [Haskell-cafe] Amazon AWS storage best to use with Haskell?
by dokondr 01 Nov '11

01 Nov '11

On Mon, Oct 31, 2011 at 6:50 PM, John Lenz <lenz(a)math.uic.edu> wrote: > 4) My code processes hundreds of messages. Every message is processed in > >> exactly the same way as the others. So the code can be easily >> parallelized. Any Haskell frameworks that will allow me to run this code >> in a simple concurrency model? >> >> > Yes, there are many options. > > http://www.haskell.org/**haskellwiki/GHC/Concurrency<http://www.haskell.org/haskellwiki/GHC/Concurrency> > > > John, thanks for detailed reply! I am looking at Haskell Concurrency wiki, but can not figure out which framework - STM, sparks, threads, etc. Amazon AWS will be able to scale? As far as I know, to scale CPU and program memory in Amazon, all you can ask from AWS is to start some number of additional extra VMs. Every VM contains a complete image of your OS and executables, all images are exactly the same. That's fine with me as currently all my workflow tasks are performed by separately compiled Haskell executables communicating via regular files. So to reformulate my question: - Does any Haskell framework exist that allow to orchestrate separate processes (NOT threads that share the same process memory)? On the other hand, in case there is a way to make Amazon AWS to scale Haskell STM, sparks, threads, etc. - I would happily rewrite my Haskell code to use these frameworks. So my second question: - Is there a way to make Amazon AWS to scale Haskell STM, sparks, threads or any other Haskell concurrency frameworks?

1 0

Figures 6 and 7 from `Programming with Arrows'?
by Captain Freako 31 Oct '11

31 Oct '11

Does anyone have figures 6 and 7, as well as the intervening unnumbered figure, from `Programming with Arrows'? Thanks, -db

1 0

is Haskell missing a non-instantiating polymorphic case?
by Adam Megacz 31 Oct '11

31 Oct '11

The title might be a bit more provocative than necessary. I'm starting to suspect that there are very useful aspects of the parametricity of System F(C) which can't be taken advantage of by Haskell in its current state. To put it briefly, case-matching on a value of type (forall n . T n) forces one to instantiate the "n", even though the branch taken within the case cannot depend on "n" (parametricity). I came up with the simplest example I could and posted it to StackOverflow, but there haven't been any successes (despite some excellent attempts!): http://stackoverflow.com/questions/7720108/ This might sound like an obscure problem, but it actually starts to get in the way of the very useful Washburn+Weirich "Boxes Go Bananas" and related PHOAS representation. I've written up a short example of the problems that happen here: The link above also includes a very rough sketch of a proposal for a "pcase" construct that doesn't instantiate its argument. Is it possible to do what I'm attempting without adding "pcase" to the language? Would "pcase" break the soundness of the type system (I don't think so) or complicate type inference (probably)? I'd be interested in any comments/thoughts/help people can offer. Thanks! - a PS, I suspect that this is somehow related to the issue that Guillemette and Monnier mention in section 5.1 of their paper on type-preserving closure conversion, although I wasn't able to find the code online in order to be sure.

4 6

Amazon AWS storage best to use with Haskell?
by dokondr 31 Oct '11

31 Oct '11

Hi, Please share your experience / ideas on AWS storage most friendly to Haskell. So far I store my data mostly in Data.Map structures serialized to text files with write / read functions. Now I was requested to move my app and data to Amazon cloud. As far as I know there are two main storage types that Amazon provides: S3 - basic block storage and SimpleDB ( http://docs.amazonwebservices.com/AmazonSimpleDB/latest/GettingStartedGuide/ ) Questions: 1) I would like to continue working with my data using abstractions similar to the ones that Data.Map provides. Any ideas how to iterate and modify SimpleDB records in a similar powerful way as provided by Data.Map? Or maybe S3? 2) It would be great to do development and testing offline without actually connecting to AWS S3 / SimpleDB. Are there any AWS simulators + Haskell libraries that will allow to do such an offline development? 3) Any experience / ideas with Haskell libs for NoSQL, not AWS-native, storages, that will run well both offline and in AWS? 4) My code processes hundreds of messages. Every message is processed in exactly the same way as the others. So the code can be easily parallelized. Any Haskell frameworks that will allow me to run this code in a simple concurrency model? Thanks! Dmitri

1 0

Efficient mutable arrays in STM
by Ben Franksen 31 Oct '11

31 Oct '11

I have an application in mind where concurrent access to large arrays (up to millions of elements) of mostly small elements (Int or Double) is common. Typical access patterns would be chunk-wise, i.e. reads or writes from index n up to index m. Imagine stuff like images, scientific data, etc. All this suggests that Control.Concurrent.STM.TArray, in its current implementation, is not appropriate. Quoting the docs: "It is currently implemented as Array ix (TVar e), but it may be replaced by a more efficient implementation in the future (the interface will remain the same, however)." An array of TVars is certainly *much* too inefficient for what I have in mind w.r.t. both memory and cpu time. In fact I had already decided to use Data.Vector.Unboxed from the vector package. I see that Data.Vector.Unboxed.Mutable provides slice :: Unbox a => Int -> Int -> MVector s a -> MVector s a Yield a part of the mutable vector without copying it. which is almost what I need... Can I use this together with unsafeIOToSTM internally inside a library to provide shared transactional access to an IOArray? The docs warn that using unsafeIOToSTM is (obviously) "highly dangerous", but for what I have in mind the listed problems are not an issue: * running the IO code multiple times is ok * aborting is ok, too * inconsistent views are ok, too The main question is: does the STM transaction actually "see" that I changed part of the underlying array, so that the transaction gets re-tried? Or do I have to implement this manually, and if yes: how? Has anyone done something like that before? (If you tried this and found it doesn't work, please tell me, it would save me a lot of work repeating the effort). Is someone working on providing a more efficient version of TArray? Would it help if I said I'd be a happy user of a better TArray? ;-) If what I sketched above is infeasible (I would not be surprised if it was, I haven't yet spent much effort trying it out), what other options do I have? Is there an internal API for the STM stuff, i.e. a C header file or something which would make it possible to add efficient TArrays? Or should I use a high-level approach, something like a Data.Sequence.Seq of medium sized chunks (TVar (IOVector e))? Any comments are highly appreciated! Cheers Ben

8 11