- Haskell-Cafe - Haskell.org

setting up property tests
by Michael Litchard 10 Dec '15

10 Dec '15

I've got a little project, based off of fizzbuzz, that I would like to write property tests for using either QuickCheck or SmallCheck. Could someone have a look at https://github.com/mlitchard/fizzbuzzfib/blob/master/src/FizzBuzz.hs and help me sort out how to write property tests?

2 1

FLOPS 2016: Call for Participation and Posters/Demos
by Oleg 10 Dec '15

10 Dec '15

FLOPS 2016: 13th International Symposium on Functional and Logic Programming March 4-6, 2016, Kochi, Japan http://www.info.kochi-tech.ac.jp/FLOPS2016/ Call for Participation and Posters/Demos Registration will be open on Monday, Dec 21, 2015. Early registration deadline is Monday, Feb 8, 2016. Poster/Demo abstract submission deadline is Monday, Jan 11, 2016. FLOPS aims to bring together practitioners, researchers and implementers of the declarative programming, to discuss mutually interesting results and common problems: theoretical advances, their implementations in language systems and tools, and applications of these systems in practice. The scope includes all aspects of the design, semantics, theory, applications, implementations, and teaching of declarative programming. FLOPS specifically aims to promote cross-fertilization between theory and practice and among different styles of declarative programming. In addition to the presentations of regular research papers, the FLOPS program includes tutorials, as well as the poster/demo session for demonstrating the tools and systems described during the talks and for presenting works-in-progress and getting the feedback. FLOPS has established a Best Paper award. The winner will be announced at the symposium. CALLS FOR POSTERS AND DEMONSTRATIONS If you wish to present a poster at FLOPS, please send the plain text abstract by e-mail to <flops2016(a)easychair.org> -- by January 11, 2016. The abstract should include the title, the names of the authors and their affiliation, along with enough details to judge its scope and relevance. We will announce the accepted submissions on January 25, 2016. The format of the poster will be announced at that time. Important Dates * Submission due: January 11, 2016 (Monday), any time zone * Notification: January 25, 2016 (Monday) INVITED TALKS Kazunori UEDA (Waseda University) The exciting time and hard-won lessons of the Fifth Generation Computer Project Atze Dijkstra (Utrecht University) UHC: Coping with Compiler Complexity TUTORIALS Andreas Abel, on Agda Atze Dijkstra, on Attribute Grammars Neng-Fa Zhou, on programming in Picat ACCEPTED PAPERS Ki Yung Ahn and Andrea Vezzosi. Executable Relational Specifications of Polymorphic Type Systems using Prolog Markus Triska. The Boolean Constraint Solver of SWI-Prolog: System Description Peng Fu, Ekaterina Komendantskaya, Tom Schrijvers and Andrew Pond. Proof Relevant Corecursive Resolution Jay McCarthy, Burke Fetscher, Max New and Robert Bruce Findler. A Coq Library For Internal Verification of Running-Times Akimasa Morihata. Incremental Computing with Abstract Data Structures Wouter Swierstra and Joao Alpuim. >From proposition to program: embedding the refinement calculus in Coq Andre Van Delft and Anatoliy Kmetyuk. Declarative Programming with Algebra Ian Mackie and Shinya Sato. An interaction net encoding of Godel's System T Arthur Blot, Pierre-Evariste Dagand and Julia Lawall. >From Sets to Bits in Coq Jeremy Yallop, David Sheets and Anil Madhavapeddy. Declarative foreign function binding through generic programming Praveen Narayanan, Jacques Carette, Wren Romano, Chung-Chieh Shan and Robert Zinkov. Probabilistic inference by program transformation in Hakaru: System description Francisco Javier Lopez-Fraguas, Manuel Montenegro and Juan Rodriguez-Hortala. Polymorphic Types in Erlang Function Specifications Remy Haemmerle, Pedro Lopez-Garcia, Umer Liqat, Maximiliano Klemen, John Gallagher and Manuel V. Hermenegildo. A Transformational Approach to Parametric Accumulated-cost Static Profiling Taus Brock-Nannestad. Space-efficient Planar Acyclicity Constraints: A Declarative Pearl

1 0

ANNOUNCE: Haskell Platform 7.10.3
by Gershom B 09 Dec '15

09 Dec '15

Haskellers, we are pleased to announce the release of Haskell Platform 7.10.3 * * get it here: https://www.haskell.org/platform/ * * Highlights include: - GHC 7.10.3 - Major version bumps to - HUnit - OpenGL - OpenGLRaw - syb - Minor version bumps to - Cabal - case-insensitive - fgl - GLUT - GLURaw - primitive Full package and version list: https://www.haskell.org/platform/contents.html GHC release notes can be found at: http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/release-7-10… This is the first release in which I've taken over as release manager. Thanks to Erik Rantapaa, Ben Gamari, Randy Polen and Jason Dagit for various platform related work; thanks to Oleg Grenrus and John Wiegley for additional testing; and thanks of course to Mark Lentczner for developing the new streamlined HP build process that has made things so much easier for all of us. * Windows Notes * The Haskell Platform on Windows now provides the MSys2 tools. These tools are needed when installing packages that use conf-tools (generally rare). These tools are not automatically placed onto the PATH in order avoid troubles due to MSys2 tools which have the same name as a standard Windows tool (e.g., echo, find, dir). * Future Plans * As per the November 13 email on "Haskell Platform Plans" (https://mail.haskell.org/pipermail/haskell-cafe/2015-November/122171.html) this is a modest release for ghc, and also a modest release for the platform, to put a capstone on the 7.10 series. Coming with the 8.0 platform we'll have lots of the exciting stuff that has been long promised, including a minimal distro without extra packages, a bundled stack binary, and a much-improved experience for installing build-type: configure packages (such as network) on Windows. Issues can be reported on the github tracker: https://github.com/haskell/haskell-platform/issues * Known Issues * As the platform builds were done from the tarballs lacking 7.10.3 release notes, those notes will not be present in the installed users' guides. However, they are available online, as in the link given above. Happy Haskelling, Gershom Bazerman, Haskell Platform release manager

2 1

parsing and printing - applicative style?
by Johannes Waldmann 09 Dec '15

09 Dec '15

Dear Cafe, what is the current state of the art (and notation) in writing combined parser/printers? (as in Rendel/Ostermann ICFP 2010, http://lambda-the-ultimate.org/node/4191 ) >From the paper I get the impression that this is, or could be, a nice showcase for Applicative and Alternative. Indeed, if parsing a text in a (programming) language is separated from semantics, then the parsing should be applicative? You don't need ">>=" since you do not compute a semantical value on the left, but just the AST, which is syntax only. But then Section 3.2 shows that Printer cannot be Applicative. Indeed, the version of "pure" in the paper (see class "Syntax delta" in Section 3.4) has type "Eq a => a -> delta a", and that's different from the Applicative that we know. But one of the many "categorial" packages on hackage can express this, meanwhile? What is the meta-search-procedure to find it? - J.W.

1 0

haddoc "modules on this system" index
by Anatoly Yakovenko 08 Dec '15

08 Dec '15

I have a bunch of dead links in file:///Users/anatolyy/Library/Haskell/share/doc/index.html like this one: file:///Users/anatolyy/Library/Haskell/ghc-7.8.3-x86_64/lib/blaze-builder-0.4.0.1/doc/html/Blaze-ByteString-Builder.html which should really be this one: file:///Users/anatolyy/Library/Haskell/ghc-7.10.1-x86_64/lib/blaze-builder-0.4.0.1/doc/html/Blaze-ByteString-Builder.html is there a way to regenerate the index from the currently installed docs? Anatoly

2 2

Re: [Haskell-cafe] [Haskell-beginners] DOOM rewritten in the Haskell programming language.
by Alexander Berntsen 07 Dec '15

07 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David, I think it would be more valuable to make a DOOM-like game than to remake DOOM. Especially if you are going to aim for funding. The free software community has had this problem for years, where we point to remakes of old games as evidence to viability. It isn't. Nobody will be swayed by Haskell DOOM. (Although I would, personally, think it interesting.) Good luck with your project. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50 WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8 Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba Ca972BfXJnFZXiYARfov =mGnp -----END PGP SIGNATURE-----

4 3

New Functional Programming Job Opportunities
by Functional Jobs 07 Dec '15

07 Dec '15

Here are some functional programming job opportunities that were posted recently: Haskell Engineer at Wagon https://functionaljobs.com/jobs/8868-haskell-engineer-at-wagon Cheers, Sean Murphy FunctionalJobs.com

1 0

Re: [Haskell-cafe] [Haskell-beginners] DOOM rewritten in the Haskell programming language.
by Henk-Jan van Tuyl 07 Dec '15

07 Dec '15

On Sun, 06 Dec 2015 16:21:15 +0100, David Blubaugh <davidblubaugh2000(a)yahoo.com> wrote: > TO ALL, > Hello My name is David Allen Blubaugh. I am currently considering > starting a kick-starter project in redeveloping the DOOM source code > with the Haskell Programming language using the power of > functional-oriented programming...... > I know that John Carmack was interested in the Haskell programming > language and had even recreated wolfenstein 3D using the Haskell > programming language. Does anybody have a copy of John Carmack's > recreation of wolfenstein 3D using haskell ??? Also would anybody enjoy > working with this project ??? What benefits would DOOM have enjoyed had > ID software created the DOOM source code in 1993 with Haskell or some > other functional-oriented programming language instead of C/assembly > programming languages ??? Thanks, > David Allen BlubaughElectrical EngineerATR Associate I don't know about his source code, but the Games page[0] lists: - hadoom A clone of Doom, using reactive-banana, GTK, and the "diagrams" library. https://github.com/ocharles/hadoom - Frag A 3D first person shooting game https://wiki.haskell.org/Frag These might be helpful. Advantages, when developing software in Haskell, are faster development with fewer bugs. Disadvantages are: the compiled programs are slower then when written in C and the garbage collection of a Haskell program (when compiled with GHC) might sometimes cause delays in screen updates. Regards, Henk-Jan van Tuyl [0] https://wiki.haskell.org/Games -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

4 3

ICFP 2016 Call for Papers
by Lindsey Kuper 07 Dec '15

07 Dec '15

                              ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming                http://conf.researchr.org/home/icfp-2016                            Call for Papers Important dates --------------- Submissions due:    Wednesday, March 16 2016, 15:00 (UTC)                     https://icfp2016.hotcrp.com                     (in preparation as of December 1) Author response:    Monday, 2 May, 2016, 15:00 (UTC) -                     Thursday, 5 May, 2016, 15:00 (UTC) Notification:       Friday, 20 May, 2016 Final copy due:     TBA Early registration: TBA Conference:         Tuesday, 20 September -                     Thursday, 22 September, 2016 Scope ----- ICFP 2016 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): - Language Design: concurrency, parallelism, and distribution;   modules; components and composition; metaprogramming; type systems;   interoperability; domain-specific languages; and relations to   imperative, object-oriented, or logic programming. - Implementation: abstract machines; virtual machines; interpretation;   compilation; compile-time and run-time optimization; garbage   collection and memory management; multi-threading; exploiting   parallel hardware; interfaces to foreign functions, services,   components, or low-level machine resources. - Software-Development Techniques: algorithms and data structures;   design patterns; specification; verification; validation; proof   assistants; debugging; testing; tracing; profiling. - Foundations: formal semantics; lambda calculus; rewriting; type   theory; monads; continuations; control; state; effects; program   verification; dependent types. - Analysis and Transformation: control-flow; data-flow; abstract   interpretation; partial evaluation; program calculation. - Applications: symbolic computing; formal-methods tools; artificial   intelligence; systems programming; distributed-systems and web   programming; hardware design; databases; XML processing; scientific   and numerical computing; graphical user interfaces; multimedia and   3D graphics programming; scripting; system administration; security. - Education: teaching introductory programming; parallel programming;   mathematical proof; algebra. - Functional Pearls: elegant, instructive, and fun essays on   functional programming. - Experience Reports: short papers that provide evidence that   functional programming really works or describe obstacles that have   kept it from working. If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ------------------------------------ - By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at   most 12 pages (6 pages for an Experience Report), in standard   SIGPLAN conference format, including figures but ***excluding   bibliography***. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. ***ICFP 2016 will employ a lightweight double-blind reviewing process.*** To facilitate this, submitted papers must adhere to two rules:  1. ***author names and institutions must be omitted***, and  2. ***references to authors' own related work should be in the third     person*** (e.g., not "We build on our previous work ..." but     rather "We build on the work of ..."). The purpose of this process is to help the PC and external reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. We have put together a document answering frequently asked questions that should address many common concerns: http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-R… - Authors have the option to attach supplementary material to a   submission, on the understanding that reviewers may choose not to   look at it. The material should be uploaded at submission time, as a   single pdf or a tarball, not via a URL. This supplementary material   may or may not be anonymized; if not anonymized, it will only be   revealed to reviewers after they have submitted their review of your   paper and learned your identity. - Each submission must adhere to SIGPLAN's republication policy, as   explained on the web at:   http://www.sigplan.org/Resources/Policies/Republication - Authors of resubmitted (but previously rejected) papers have the   option to attach an annotated copy of the reviews of their previous   submission(s), explaining how they have addressed these previous   reviews in the present submission. If a reviewer identifies   him/herself as a reviewer of this previous submission and wishes to   see how his/her comments have been addressed, the program chair will   communicate to this reviewer the annotated copy of his/her previous   review. Otherwise, no reviewer will read the annotated copies of the   previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are given below. Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from at least one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard SIGPLAN conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available at http://www.sigplan.org/Resources/Author/ Submission: Submissions will be accepted at https://icfp2016.hotcrp.com (in preparation as of December 1). Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 15:00 UTC on Monday, 2 May, 2016, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for free downloads from the ACM DL. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Special categories of papers ---------------------------- In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to six pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ================= A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: - a new and thought-provoking way of looking at an old idea - an instructive example of program calculation or proof - a nifty presentation of an old or new data structure - an interesting application of functional programming techniques - a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission you wish to have treated as a pearl must be marked as such on the submission web page, and should contain the words ``Functional Pearl'' somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. Experience Reports ================== The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works -- or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: - insights gained from real-world projects using functional   programming - comparison of functional programming with conventional programming   in the context of an industrial project or a university curriculum - project-management, business, or legal issues encountered when using   functional programming in a real-world project - curricular issues encountered when using functional programming in   education - real-world constraints that created special challenges for an   implementation of a functional language or for functional   programming in general An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. - Both in the proceedings and in any citations, the title of each   accepted Experience Report must begin with the words ``Experience   Report'' followed by a colon. The acceptance rate for Experience   Reports will be computed and reported separately from the rate for   ordinary papers. - An Experience Report is at most six pages long. Each accepted   Experience Report will be presented at the conference, but depending   on the number of Experience Reports and regular papers accepted,   authors of Experience reports may be asked to give shorter talks. - Because the purpose of Experience Reports is to enable our community   to accumulate a body of evidence about the efficacy of functional   programming, an acceptable Experience Report need not add to the   body of knowledge of the functional-programming community by   presenting novel results or conclusions. It is sufficient if the   Report states a clear thesis and provides supporting evidence. The   thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. If functional programming worked for you in the same ways it has worked for others, you need only to summarize the results?the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you are unsure in which category to submit, the program chair will be happy to help you decide. Organizers ---------- General Co-Chairs: Jacques Garrigue (Nagoya University) Gabriele Keller (University of New South Wales) Program Chair: Eijiro Sumii (Tohoku University) Program Committee: Koen Claessen (Chalmers University of Technology) Joshua Dunfield (University of British Columbia, Canada) Matthew Fluet (Rochester Institute of Technology) Nate Foster (Cornell University) Dan Grossman (University of Washington, USA) Jurriaan Hage (Utrecht University) Roman Leshchinskiy (Standard Chartered Bank) Keisuke Nakano (The University of Electro-Communications) Aleksandar Nanevski (IMDEA Software Institute) Scott Owens (University of Kent) Sungwoo Park (Pohang University of Science and Technology) Amr Sabry (Indiana University) Tom Schrijvers (KU Leuven) Olin Shivers (Northeastern University) Walid Taha (Halmstad University) Dimitrios Vytiniotis (Microsoft Research, Cambridge) David Walker (Princeton University) Nobuko Yoshida (Imperial College London, UK) External Review Committee to be announced.

1 1

Type family weirdness
by David Feuer 06 Dec '15

06 Dec '15

If I have {-# LANGUAGE PolyKinds, TypeFamilies #-} import Data.Type.Coercion type family X :: k and I want coercionXX :: Coercion X X, the obvious thing, coercionXX = Coercion, doesn't work: Couldn't match representation of type ‘X’ with that of ‘X’ NB: ‘X’ is a type function, and may not be injective Relevant role signatures: type role X nominal Relevant bindings include coercionXX :: Coercion X X (bound at Fold.hs:167:1) In the expression: Coercion In an equation for ‘coercionXX’: coercionXX = Coercion However, if I write coercionXX = x where x = Coercion, that does work! What gives?

2 2