December 2011 - Haskell-Cafe

CfP: Extended Submission Deadline TAP 2012 (International Conference on Test and Proofs)
by Achim D. Brucker 19 Dec '11

19 Dec '11

(Apologies for duplicates) ************************************************************ *** TAP 2012 offers extended submission deadlines due to *** *** numerous requests received: *** *** Abstract submission: January 11, 2012 *** *** Paper submission: January 18, 2012 *** ************************************************************ *** TAP 2012 solicits both full papers and (industrial) *** *** experience/tool papers *** *** in combining proofs and (security) testing. *** ************************************************************ CALL FOR PAPERS Full and short Research Paper, Industrial Experience Papers, Tool Papers Abstract submission: Jan 11, 2012, Paper submission Jan 18, 2012 6th INTERNATIONAL CONFERENCE ON TEST AND PROOFS (TAP 2012) http://lifc.univ-fcomte.fr/tap2012/ May 31 - June 1, 2012, Prague, Czech Republic Part of the TOOLS Federated Conferences 2012 http://tools2012.fit.cvut.cz/ The TAP conference is devoted to the convergence of proofs and tests, to the application of techniques from both sides and their combination for the advancement of software quality. Test and Proof seem to be contradictory techniques: if you have proved your program to be correct, it is fruitless to comb it for bugs; and if you are testing it, that is surely a sign that you have given up on any hope to prove its correctness. Accordingly, proofs and tests have, since the onset of software engineering research, been pursued by distinct communities. However, the development of both approaches lead to the discovery of common issues and to the realization that each may need the other. The emergence of model checking has been one of the first signs that contradiction may yield to complementarity. Further evidence give test data generation techniques from models or programs which boil down to constraint resolution techniques for relatively large formula; the advent of powerful SMT solvers have therefore powered new testing techniques. Finally, since formal, proof-based verification is costly, testing invariants and background theories can be helpful to detect errors early and to improve cost effectivity. 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): - 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 - Applying combination of test and proof techniques to new application domains such as validating security procotols or vulnerability detection of programs Important Dates: ================ Abstract submission (extended): January 11, 2012 Paper submission (extended): January 18, 2012 Notification: March 2, 2012 Camera ready version: March 19, 2012 TAP conference: May 31 - June 1, 2012 TOOLS conferences (TOOLS, ICMT, SC, TAP): May 29 - June 01, 2012 Conference Chairs: Bertrand Meyer Program Chairs: Achim D. Brucker and Jacques Julliand Program Committee (to be extended): =================================== Nazareno Aguirre, Bernhard K. Aichernig, Paul Ammann, Dirk Beyer, Nikolaj Bjorner, Robert Clarisó, Marco Comini, Catherine Dubois, Gordon Fraser, Angelo Gargantini, Alain Giorgetti, Patrice Godefroid, Martin Gogolla, Arnaud Gotlieb, Reiner Hähnle, Bart Jacobs, Thierry Jéron, Gregory Kapfhammer, Nikolai Kosmatov, Victor Kuliamin, Karl Meinke, Jeff Offutt, Holger Schlingloff, T.H. Tse, Margus Veanes, Luca Viganò, Burkhart Wolff, Fatiha Zaidi Submission: =========== Please submit your papers via http://lifc.univ-fcomte.fr/tap2012/. TAP 2012 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. 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 Research, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, Fax: +49-6227 78-50502, http://www.brucker.ch

1 0

Splitting off many/some from Alternative
by Gregory Crosswhite 19 Dec '11

19 Dec '11

Hey everyone, I am sure that it is too late to do more than idly speculate about this, but could we split the some/many methods out from Alternative? They simply don't make sense except in a subset of possible Alternatives --- in most cases they just result in an infinite loop. That is to say, it is not just that they are extraneous functionality, but most of the time they are *impossible* functionality to even implement! In a way, it is a lie to be including them in Alternative since people making use of the class might incorrectly (but quite reasonably!) assume that any type that is an instance of Alternative *has* a well-defined some and many method, when this is actually the exception rather than the rule. It is only recently that I have been able to grok what some and many are even about (I think), and they seem to only make sense in cases where executing the Alternative action results in a portion of some input being consumed or not consumed. "some v" means "consume at least one v and return the list of items consumed or fail", and "many v" means "consume zero or more v and return the list of items consumed or the empty list of none are consume". It thus makes sense for there to be some subclass of Alternative called something like "Consumptive" that contains these methods. The majority of "Alternative" instances would no longer have these methods, and again that would actually be an improvement since in such cases some/many were unworkable and did nothing but cause infinite loops anyway. Normally it would be unthinkable to even consider such a change to the base libraries, but I suspect that there are not more than a couple of packages out there that make active use of the some/many instances of Alternative; it is really only parser packages that need some/many, and users most likely use the versions included with the packages themselves rather than the Alternative version. Could we verify that this is the case, and if so split them away? I thought I heard a trick whereby people were able to grep all the source on Hackage, but I can't remember what it was. :-) Just a thought. :-) Thanks, Greg

15 37

Sharing on equality
by Johan Brinch 19 Dec '11

19 Dec '11

Hey all, Can GHC eliminate one of two equal ByteStrings, when they are compared and turns out to be equal? Say i have a map, ByteString -> Int. I now do a lookup on a ByteString and if it exists, I insert this ByteString into a list. Is it possible to avoid using more memory, than used by the keys in the map + the list structure? I.e. is it possible to eliminate the redundant ByteStrings somehow? I guess, this could be done by having lookup return the key as well, and then insert this key into the list, however, that's a bit ugly and somewhat anti-intuitive. Here's an example program, to illustrate the idea: https://gist.github.com/1472418 -- Johan Brinch

3 2

Idiomatic Aeson
by Rune Harder Bak 19 Dec '11

19 Dec '11

Hi I'm trying to parse a nested structure using Aeson (from Facebook) It looks something like this: { "education": [ { "school": { "name": "A" }, }, { "concentration": [ { "name": "B" } } ]} And besides this there is a lot of fields I don't need. (And a lot of other fields I do need) What is the idiomatic aeson way of doing this? I'm using Aeson because it's fast, and it seams to have all the relevant combinators, just can't get them to play nicely together. I was thinking something like getInfo (Object m) = (,) <$> m .: "school" .: "name" <*> mapM (.: "name") (m .: "concentracion") but of cause the types don't add up. the verbose style like getInfo (Object m) = do school <- m .: "school" schoolName <- case school of Object m' -> m' .: "name" l -> typeMismatch "schoolName" l concentration <- m .: "concentration" concentrationName <- case concentration of Array l -> forM (V.toList l) $ \m' -> case m' of Object m' -> m' .: "name" l -> typeMismatch "concentrationName" l ) o -> typeMismatch "parseList" o return (schoolName,concentrationName) quickly explodes. So I wrote my own functions of the following sort parseName name _ (Object m) = m .: name parseName _ err l = typeMismatch err l parseList p (Array l) = mapM p $ V.toList l parseList _ o = typeMismatch "parseList" o so I can do something like getInfo (Object m) = (,) <$> parseName "school "school" m >>= parseName "name" "schoolName" <*> parseName "concentration" "concentration" m >>= parseList (parseName "name" "concentrationName") And then variants for for .:?, but then it gets messy with >>= and maybe. Getting rid of the m in the above I moved to arrows, and.. it seems I'm not understanding the standard combinators. So.. what is the idiomatic way of doing this in Aeson? It shouldn't be necessary to move to template-haskell/generics to do this! Thanks!

2 1

compare lengths of lists lazily
by Henning Thielemann 19 Dec '11

19 Dec '11

Shortest and most obfuscating solution I found is: import Data.Ord (comparing) import Control.Applicative ((<$)) compareLength :: [a] -> [a] -> Ordering compareLength = comparing (()<$) :-)

3 2

PEPM'12 - second call for participation
by Simon Thompson 19 Dec '11

19 Dec '11

ACM SIGPLAN 2012 Workshop on Partial Evaluation and Program Manipulation http://www.program-transformation.org/PEPM12 January 23-24, 2012. Philadelphia, PA, USA (co-located with POPL'12) Second Call For Participation Online registration is open at https://regmaster3.com/2012conf/POPL12/register.php Early registration deadline is December 24, 2011 Program is now available http://www.program-transformation.org/PEPM12/Program The PEPM Symposium/Workshop series brings together researchers and practitioners working in the broad area of program transformation, which spans from refactoring, partial evaluation, supercompilation, fusion and other metaprogramming to model-driven development, program analyses including termination, inductive programming, program generation and applications of machine learning and probabilistic search. PEPM focuses on techniques, supporting theory, tools, and applications of the analysis and manipulation of programs. In addition to the presentations of regular research papers, the PEPM program includes tool demonstrations and `short paper' presentations of exciting if not fully polished research. PEPM has established a Best Paper award. The winner will be announced at the workshop. INVITED TALKS Compiling Math to High Performance Code Markus Pueschel (ETH Zuerich, Switzerland) http://www.inf.ethz.ch/~markusp/index.html Specification and verification of meta-programs Martin Berger (University of Sussex, UK) http://www.informatics.sussex.ac.uk/users/mfb21/ VENUE The conference is co-located with POPL and will be held at the Sheraton Society Hill Hotel in Philadelphia's historic district. For hotel rate details and booking please see the POPL webpage: http://www.cse.psu.edu/popl/12/ Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

1 0

[Alternative] summary of my understanding so far
by Gregory Crosswhite 19 Dec '11

19 Dec '11

Hey everyone! First of all, it sounds like we all agree that the documentation for Alternative needs to be improved; that alone would clear a lot of the confusion up. I think that a fairly convincing case has also been made that removing many/some from the typeclass doesn't help too much since they are generically defined in terms of the other methods. Put another way, arguing that removing many/some makes Alternative more safe would be like arguing that removing "forever" from the definition of Monad (assuming it were currently a method rather than a function) made Monad more safe. (On the other hand, it might be nice if many/some were not featured so prominently above other functions/combinators in the module.) As a corollary to the above paragraph, if the many/some methods *were* moved to a subclass --- call it, "Parser" --- then essentially this subclass would be redundant. Nonetheless, such a subclass could still be useful because it supplies more information to the user about how the type behaves. That is, while any user of an instance of Alternative can always theoretically use something like many/some, in practice a user might want to add the Parser constraint to their type just to get an extra guarantee that many/some not only exist but are well-behaved. Although many/some cause infinite loops for the current instance of Maybe and [], forever also causes loops for (return (undefined)) for any Monad. Thus, even in the likely event that we decide to keep many/some in Alternative, it still makes sense to have Alternative instances for Maybe and [], despite the fact that they don't play well with many/some for non-empty values. In fact, if anything the existence of the Maybe and [] instances provides a strong reason *to* have the many/some methods inside Alternative, precisely because it gives us a customization point that allows us to make many and some provide well-defined answers for all values of these types. To quote Ross Paterson's proposals: instance Alternative Maybe where ... some Nothing = Nothing some (Just x) = Just (repeat x) many Nothing = Just [] many (Just x) = Just (repeat x) instance Alternative [] where ... some [] = [] some (x:xs) = repeat (repeat x) many [] = [[]] many (x:xs) = repeat (repeat x) The only price that we pay for these instances is that, while some and many are still solutions of • some v = (:) <$> v <*> many v • many v = some v <|> pure [] they no longer the *least* solutions of these equations. In my opinion this is a relatively small price to pay since they nonetheless *are* solutions to these questions, and they have the nice property that they converge sensibly. In fact, in a sense they are the least solutions to the equations that out of all the solutions that converge, though I don't know enough about the theory involved to use the proper technical terminology to express what I really mean, or even if what I just wrote was true. :-) Anyway, as the above discussion illustrates, the existence of pure types that are instances of Alternative actually *adds* to the case of keeping some and maybe in Alternative. So in conclusion: 1) Documentation really needs to be improved 2) some/many cannot be physically separated from Alternative, but there *might* be an advantage to creating a subclass for them anyway purely for the sake of conveying more information about a type to users 3) Maybe and [] are sensible instances of Alternative, even if many/some often enters an infinite loop. 4) It is possible to provide special instance of many/some that satisfy the equations of many/some, with the slight disadvantage that these solutions are no longer the "least" solutions. Based on all of this, at this moment in time it seems to me that the most sensible way forward is to fix the documentation, tweak the definition of Alternative to no longer require the least solutions of the equations, and then to adopt the new instances for Maybe and []. Thoughts? Cheers, Greg

7 16

PEPM12: Second Call For Participation
by oleg＠okmij.org 18 Dec '11

18 Dec '11

ACM SIGPLAN 2012 Workshop on Partial Evaluation and Program Manipulation http://www.program-transformation.org/PEPM12 January 23-24, 2012. Philadelphia, PA, USA (co-located with POPL'12) Second Call For Participation Program is now available http://www.program-transformation.org/PEPM12/Program Online registration is open at https://regmaster3.com/2012conf/POPL12/register.php Early registration deadline is December 24, 2011 The PEPM Symposium/Workshop series brings together researchers and practitioners working in the broad area of program transformation, which spans from refactoring, partial evaluation, supercompilation, fusion and other metaprogramming to model-driven development, program analyses including termination, inductive programming, program generation and applications of machine learning and probabilistic search. PEPM focuses on techniques, supporting theory, tools, and applications of the analysis and manipulation of programs. In addition to the presentations of regular research papers, the PEPM program includes tool demonstrations and `short paper' presentations of exciting if not fully polished research. PEPM has established a Best Paper award. The winner will be announced at the workshop. INVITED TALKS Compiling Math to High Performance Code Markus Pueschel (ETH Zuerich, Switzerland) http://www.inf.ethz.ch/~markusp/index.html Specification and verification of meta-programs Martin Berger (University of Sussex, UK) http://www.informatics.sussex.ac.uk/users/mfb21/ VENUE The conference is co-located with POPL and will be held at the Sheraton Society Hill Hotel in Philadelphia's historic district. For hotel rate details and booking please see the POPL webpage: http://www.cse.psu.edu/popl/12/

1 0

Type checker for haskell-src-exts (was: Typechecking Using GHC API)
by Sean Leather 18 Dec '11

18 Dec '11

On Thu, Dec 15, 2011 at 11:07, Niklas Broberg wrote: > Envisioned: The function you ask for can definitely be written for > haskell-src-exts, which I know you are currently using. I just need to > complete my type checker for haskell-src-exts first. Which is not a small > task, but one that has been started. That's good to know! I presume it's something like Haskell98 to start with? I'd be even more impressed (and possibly also concerned for your health) if you were going to tackle all of the extensions! I've been trying to find a student to write a haskell-src-exts type checker for me. It should use a particular kind of mechanism though, using constraints similar to [1]. Then, I want to adapt that to do transformations. What approach are you using? Maybe I can somehow steal your work... ;) Regards, Sean [1] http://www.staff.science.uu.nl/~heere112/phdthesis/

4 6

Adding state to a library
by Kevin Jardine 18 Dec '11

18 Dec '11

I have a library of functions that all take cfg parameter (and usually others) and return results in the IO monad. It is sometimes useful to drop the config parameter by using a state-like monad.. I have found that I can wrap all my functions like so: withLibrary cfg f = f cfg stateF a b c d =

2 3