November 2011 - Haskell-Cafe

Re: [Haskell-cafe] How to implement digital filters using Arrows
by Captain Freako 01 Nov '11

01 Nov '11

Hi John, Thanks for all your help. I've been studying your suggested code: > type FilterAu b c = Automaton (->) b c > liftAu :: ((x,FilterState s)->(y,FilterState s)) -> FilterState s -> FilterAu x y > liftAu f s0 = proc x -> do > rec (y,s') <- arr f -< (x,s) > s <- delay s0 -< s' > returnA -< y runAutomaton is a bit cumbersome, so define a custom run function that takes a list > runAuto a [] = [] > runAuto (Automaton f) (x:xs) = let > (y,a) = f xt > in y:runAuto a xs as well as the various instance definitions for Automaton. I think I understand how the `returnA' in the last line of your `liftAu' function is getting translated by those instance definitions into: c where c = Automaton ( arr id &&& arr (const c) ) and, furthermore, how that is passing the supplied `y' into the first element of the resulting couple. However, I don't understand how the recursively defined `c' is capturing the modified filter state and preserving it for the next call. It seems like the Automaton being referred to by `c' is a newly constructed entity, which knows nothing about the current state of the running Automaton. Any help in understanding this would be greatly appreciated. Thanks! -db

3 7

happstack file serving
by Antoine Latter 01 Nov '11

01 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