December 2012 - Haskell-Cafe

Incremental regular expressions - article and library
by Eugene Kirpichov 18 Dec '12

18 Dec '12

Hi Haskellers, I just published an article that can be interesting to lovers of functional programming, even though it's not directly relevant to Haskell per se. http://jkff.info/articles/ire/ It's based on Dan Piponi's blogpost "Fast incremental regular expression matching with monoids" http://blog.sigfpe.com/2009/01/fast-incremental-regular-expression.html but expands Dan's ideas to include *locating* matches, matching multiple regular expressions at once, using a more compact datastructure than fingertrees, etc. And - sorry - the implementation is in Java, for reasons explained in the article :) -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov

1 0

HTF & Quickcheck
by graham＠fatlazycat.com 18 Dec '12

18 Dec '12

Getting test failures, I believe, due to using conditional properties within quickckeck etc [TEST] RecFunSpec:map (test/RecFunSpec.hs:48) Gave up! Passed only 20 tests. *** Failed! (2ms) Is there a way for HTF/Quickcheck to specify these are not failed i.e. only fail if there is an actual error ? Thanks

3 7

Race Condition in threads
by mukesh tiwari 18 Dec '12

18 Dec '12

Hello All I have two questions. 1. I wrote this code to create 10 simultaneous threads. Could some one please tell me if this is correct or not ? incr_count :: MVar () -> MVar Int -> IO () incr_count m n = ( forM_ [ 1..10000 ] $ \_ -> modifyMVar_ n ( return . ( + 10 ) ) ) >> putMVar m () main :: IO() main = do count <- newMVar 0 list <- forM [1..10] $ \_ -> newEmptyMVar forM_ list $ \var -> forkIO . incr_count var $ count forM_ list $ \var -> takeMVar var val <- takeMVar count print val 2. I am trying to create race condition which makes the variable in inconsistent state. Could some one please tell me how to achieve this ? I look at IORef but it does not have function like modifyMVar_. Mukesh Tiwari

2 2

TAP 2013: 2nd Call for Papers
by Achim D. Brucker 18 Dec '12

18 Dec '12

(Apologies if you receive this announcement multiple times.) **************************************************** *** *** *** TAP 2013 *** *** *** *** Abstract submission: January 25, 2013 *** *** Paper submission: February 1, 2013 *** **************************************************** *** TAP 2013 solicits both full papers and *** *** (industrial) experience/tool papers *** *** in combining proofs and (security) testing *** **************************************************** CALL FOR PAPERS 7th INTERNATIONAL CONFERENCE ON TESTS AND PROOFS (TAP 2013) http://www.spacios.eu/TAP2013 Budapest, Hungary, June 18-19, 2013 The TAP conference is devoted to the synergy of proofs and tests, to the application of techniques from both sides and their combination for the advancement of software quality. Testing and proving seem to be contradictory techniques: once you have proved your program to be correct then additional testing seems pointless; on the other hand, when such a proof in not feasible, then testing the program seems to be the only option. This view has dominated the research community since the dawn of computer science, and has resulted in distinct communities pursuing the seemingly orthogonal research areas. However, the development of both approaches has lead to the discovery of common issues and to the realization of potential synergy. Perhaps, use of model checking in testing was one of the first signs that a counterexample to a proof may be interpreted as a test case. Recent breakthroughs in deductive techniques such as satisfiability modulo theories, abstract interpretation, and interactive theorem proving, have paved the way for new and practically effective methods of powering testing techniques. Moreover, since formal, proof-based verification is costly, testing invariants and background theories can be helpful to detect errors early and to improve cost effectiveness. Summing up, in the past few years an increasing number of research efforts have encountered the need for combining proofs and tests, dropping earlier dogmatic views of incompatibility and taking instead the best of what each of these software engineering domains has to offer. The TAP conference aims to bring together researchers and practitioners working in the converging fields of testing and proving, and will offer a generous allocation of papers, panels and informal discussions. Topics of interest cover theory definitions, tool constructions and experimentations, and include (other topics related to TAP are welcome): - Bridging the gap between concrete and symbolic techniques, e.g. using proof search in satisfiability modulo theories solvers to enhance various testing techniques - Transfer of concepts from testing to proving (e.g., coverage criteria) and from proving to testing - Program proving with the aid of testing techniques - New problematics 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 - Model-based testing and verification - Generation of specifications by deduction - Automatic bug finding - Debugging of programs combining static and dynamic analysis - Formal frameworks - Tool descriptions and experience reports - Case studies combining tests and proofs - Domain specific applications of testing and proving to new application domains such as validating security protocols, vulnerability detection of programs, security Important Dates: ================ Abstract submission: January 25, 2013 Paper submission: February 1, 2013 Notification: March 3, 2013 Camera ready version: April 5, 2013 TAP conference: June 17-21, 2013 Program Chairs: =============== Margus Veanes (Microsoft Research, USA) Luca Vigano` (University of Verona, Italy) Program Committee: ================== Paul Ammann Dirk Beyer Achim D. Brucker Robert Clarisò Marco Comini Catherine Dubois Gordon Fraser Angelo Gargantini Christoph Gladisch Martin Gogolla Arnaud Gotlieb Wolfgang Grieskamp Reiner Hähnle Bart Jacobs Thiérry Jeron Jacques Julliand Gregory Kapfhammer Nikolai Kosmatov Victor Kuliamin Michael Leuschel Karl Meinke Alexandre Petrenko Holger Schlingloff T.H. Tse Margus Veanes (co-chair) Luca Viganò (co-chair) Burkhart Wolff Fatiha Zaidi Submission: =========== Please submit your papers via easychair https://www.easychair.org/conferences/?conf=tap2013 TAP 2013 will accept two types of papers: - Research papers: full papers with at most 16 pages in LNCS format (pdf), which have to be original, unpublished and not submitted elsewhere. - Short contributions: work in progress, (industrial) experience reports or tool demonstrations, position statements; an extended abstract with at most 6 pages in LNCS format (pdf) is expected. Subject to final approval by Springer, accepted papers will be published in the Springer LNCS series and will be available at the conference. The contents of previous TAP proceedings is available at: http://www.informatik.uni-trier.de/~ley/db/conf/tap/ -- Dr. Achim D. Brucker, SAP AG, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch/

1 0

haskell-like scripting language
by Christopher Howard 17 Dec '12

17 Dec '12

I gave Shelly a try. Pretty cool - using it for some of the scripts on my system. Has me wondering though: is anyone working on creating a actual Haskell-like scripting language and engine? Shelly is cool, as I said, but I imagine it would be more valuable to have another language that is actually separate from Haskell, with an interpreter that is more lightweight and changes much less frequently (than GHC). Something that could be nearly as portable as Bash or Perl. -- frigidcode.com

2 1

Navigating 'Strategic' programming babel
by Ravi Sahni 17 Dec '12

17 Dec '12

Clearly Haskell has great possibilities in the field of language-processing. And the nuisances associated with little actual computation buried under much data-structure navigation are well addressed by 'strategic-programming' systems. But now comes the rub -- there seem to be a lot of very similar systems. Any guidance on which/what/how to choose? My own current sketchy-patchy knowledge is as below. I would appreciate links/pointers to more substansive literature. First there was Meertens and his folks working on generic haskell Did that later become template haskell? That branched out into strafunski, stratego/xt. SYB is ___ not sure here: some literature suggests that its identical to strafunski. Some suggests that it is strafunski done more within the haskell language rather than in libraries. Then there's uniplate. How does it compare to SYB? Or is that a confused comparison?

4 4

ANN: Haskell bindings for the igraph C library
by Nils Schweinsberg 17 Dec '12

17 Dec '12

Hi Haskellers, dear igraph community, I am pleased to announce the release of our (inofficial) Haskell bindings to the igraph C library. igraph is a powerfull library for creating and manipulating directed, undirected and weighted graphs. Our package offers a complete coverage of all functions on structural properties of graphs. Compared to the official packages for R and Python it is the first library that offers type level distinction between directed/undirected and weighted graphs. Haskells type system allows to keep track of the types of your nodes and whether or not your graph and its edges are directed or undirected, weighted or unweighted. Haskell graphs may contain any Haskell value as node values, kind of similar to Pythons attributes. igraph on hackage, the official package database for Haskell: http://hackage.haskell.org/package/igraph (requires the current igraph-0.6 C library) The official igraph website: http://igraph.sourceforge.net/index.html Until hackage generates the haddock documentation, the documentation is also available at: http://hs.nils.cc/igraph-0.1/html/index.html Any feedback is appreciated, - Nils Schweinsberg - George Giorgidze

2 2

Cabal: Retrieve directory in which binaries get installed
by Björn Peemöller 17 Dec '12

17 Dec '12

Hello cafe, I'd like to retrieve the path in which binaries get installed when I `cabal install` a package. Normally, this would be ~/.cabal/bin on my Linux, but since I share my home folder on two architectures, in ~/.cabal/config I set the user-install prefix to ~/.cabal/$arch, so binaries get installed to ~/.cabal/$arch/bin. I have the feeling that it should be rather simple to retrieve the FilePath from the Cabal API, does anyone know how to do this? Thanks in advance, Björn

2 1

ANN: JMacro 0.6 and JMacro-RPC, featuring cross-platform json-rpc, easy AJAX applications, evented reactive panels and more
by Gershom Bazerman 16 Dec '12

16 Dec '12

jmacro: http://hackage.haskell.org/package/jmacro jmacro-rpc: http://hackage.haskell.org/package/jmacro-rpc jmacro-rpc-snap: http://hackage.haskell.org/package/jmacro-rpc-snap jmacro-rpc-happstack: http://hackage.haskell.org/package/jmacro-rpc-happstack I'm happy to announce the release of JMacro 0.6 (0.6.3 actually) which brings a host of improvements. JMacro is a quasiquoted library for the programmatic generation of JavaScript code. It lets you write in a superset of JavaScript with haskell-like syntax and compile-time guarantees of syntactic correctness, and is intended to be used for both embedded javascript and compilers and libraries targeting JavaScript--where hygienic naming, proper scoping, and anti-quotation are especially important. Documentation is on the Haskell Wiki: http://www.haskell.org/haskellwiki/Jmacro This release brings a host of improvements to efficiency, driven largely by user-submitted patches and requests. Text is used more uniformly, as opposed to String, and JSON integration is provided via aeson rather than the json package. Additionally, nearly all of JavaScript is supported, including more obscure operators, as well as labels, and labeled break and continue. The big news, however, is JMacro-RPC, which provides multi-server tools for serving JSON-RPC 2.0 [1] remote procedure calls, as well as binding to them from both Haskell and JavaScript. On the Haskell side, rpc server functions and caller stubs are automatically generated by typeclasses. On the JavaScript side, which is less typed, a function is exposed to marshall javascript function arguments directly into RPC calls to a located URL. [1] http://jsonrpc.org/specification On top of these RPCs, JMacro-RPC provides the conversation page abstraction, which allows the easy creation of web-applications with server side state. The user simply provides a function from JavaScript -> Page that splices in some JavaScript, and a list of functions they wish to be accessible from the page. All JavaScript within the page then has access to these functions, which run, transparently, server-side, with access to page-invocation-local shared state. Backends exist for JMacro-RPC for Happstack and Snap, and can be easily written for any other server or framework. JMacro-RPC now also provides the Panels library, which is even higher-level, providing the convenience of continuation-style web development with no scaling hassle. On the server side, Panels are entirely stateless, storing no client-specific state (so requests can be sharded to multiple servers as well without worrying about session replication). Code is written with a set of combinators over Panels, which package up display and behavior simultaneously. Panels, inspired by FRP, can provide Signals, which are sampleable, Events, which are discrete and can trigger updates, and Sinks which can be bound to Signals (behaving similarly to FRP wormholes). Semantics, by virtue of client-server interaction, are necessarily evented rather than continuous. As such, this is properly a system for declarative, event-driven reactivity rather than genuine FRP. Such a system is impoverished compared to the richer continuous-time or fully stream-based discrete-time semantics provided by of real FRP libraries. However, it is more than powerful enough for the sorts of user interfaces Panels are designed to build, and holds the added advantage of being straightforward, tractable, and a tight fit for client-server interactions. While Signals are applicative and Sinks are contravariant functors, which exposes at least some flavor of FRP, simple Signals and Sinks which don't require server-side processing (and are safely distinguished as such by types) can be bound to one-another purely on the client-side, avoiding unnecessary round-trips. The Panels code combines concepts from FRP [1][2], Self-Adjusting Computation [3], ASP.NET update panels [4], and research in stable naming schemes for bound variables [5]. The JavaScript "rts" driving evented updates is designed to be reasonably efficient and leak-free. Between basic RPCs, Conversations, and Panels, JMacro-RPC is intended to provide the full "power scale" for writing robust AJAX web applications with complex server-side logic. Because it is designed to be usable from any Haskell web framework or server, it is suitable for widespread adaptation. Patches, bug-reports, contributions, feature requests, documentation, etc. all are very welcome. [1] http://www.haskell.org/haskellwiki/Functional_Reactive_Programming [2] http://stackoverflow.com/questions/1028250/what-is-functional-reactive-prog… [3] http://www.umut-acar.org/self-adjusting-computation [4] http://msdn.microsoft.com/en-us/library/bb399001(v=vs.100).aspx [5] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.66.6645 ("I am not a number: I am a free variable", McBride and McKinna. See section four, on hierarchical names.) Cheers, Gershom

1 0

Re: [Haskell-cafe] edge: compile testing
by John Lato 16 Dec '12

16 Dec '12

> > From: Christopher Howard <christopher.howard(a)frigidcode.com> > > On 12/14/2012 07:05 PM, Clark Gaebel wrote: > > Unacceptable argument type in foreign declaration > > Thanks for giving it a try. Could you send off a bug report to the > OpenAL Haskell module maintainer? <sven.panne(a)aedion.de> > > (I might offer to do it, but I tried to e-mail him once about a > different issue and never heard back. Probably didn't make it through > his spam filter.) I think Sven's been incommunicado for a few years now. Most likely somebody else will need to step forward as the OpenAL maintainer, if there's interest in keeping that package current. John L.

1 0