- Haskell-Cafe - Haskell.org

a problem I can't solve simply
by Dennis Raddle 14 Dec '15

14 Dec '15

I have a problem that doesn't seem hard to state but I can't seem to solve without a bunch of complex code. This relates to my musical score playback. In using it to play music, I don't always want to play back the entire source musical document, but rather play a range of measures. So I might give a command to my app like "play 1-3" which means play measures 1 through 3. There is a time saving feature, which is that I can type "play 10" which means start the playback at measure 10 and continue until the first occurrence of two empty measures. This is a common use case. So I have to write a function that takes a start measure and computes the end measure by scanning for two empty measures. Let's say for simplicity's sake that we'll forget about "measures" and just say that notes have a start time and end time, which will be integers. type Note = (Int,Int) A musical score can have several individual staves (notes for individual instruments), so it will look like this: type Staff = [Note] type Score = [Staff] I need to write a function as follows computeEndMsr :: Int -> Score -> Int computeEndMsr beginMsr score = ... Some examples: Here's a score with just one staff, to give you an idea. score1 = [ [(1,3), (2,4), (7,10)] ] -- In the following case a two-unit gap is found at units 5 and 6. computeEndMsr 1 score1 = 4 computeEndMsr 5 score1 = should throw an error indicating that a gap was found immediately and no actual notes were included -- In the following case, the maximum unit of any note is 10, so that is what is computed computeEndMsr 6 score1 = 10 -- This case illustrates how it's okay if the computed end measure is equal to the begin msr computeEndMsr 10 score1 = 10 computeEndMsr 11 score1 = should throw an error indicating that the given begin msr is past the end of any note in the score This example has only one staff, but a score can have multiple staves. Also the timing and duration of notes can overlap, either on one staff or across multiple staves.

2 2

Applicative banana brackets
by martin 14 Dec '15

14 Dec '15

Hi, while learning about all the type classes and their relationships I came across something I found weird. If I understand it correctly, banana brackets where originally developed for Applicatives. The intent was to enable us to write something like (| (\a b c -> a + b + c), [3], [1,2], [5,0,7] |) and have it translated to liftA3 (\a b c -> a + b + c) [3] [1,2] [5,0,7] or alternatively, to allow us to write something like (| (pure $ \a b c -> a + b + c), [3], [1,2], [5,0,7] |) and have it translated directly to pure (\a b c -> a + b + c) <*> [3] <*> [1,2] <*> [5,0,7] A variant of banana brackets is implemented in ghc, but only for Arrows as part of -XArrowSyntax. Arrows are just the intersection of Applicative and Category, so this implementation seems to be a specialization. What's worse, I don't think -XRebindableSyntax extends to banana brackets. But why? Is it hard to have the notation work with both? (After all, the relationship between Arrows and Applicatives is not easily expressed in Haskell.) Was the demand for (Applicative) bananas not big enough? Is it just a relic? And more to the point: I have not looked at the ghc code base at all yet, but it's on my bucket list to hack on it one day. Right now, a generalization of banana brackets seems like a simple enough low pressure first project, but I fear that it might break code or that there is some pitfall I'm not seeing. Can anybody shed a bit of light on this? Thanks and cheers, Martin L. P.S.: If the list receives this mail several times, I apologize. The list management tool seems to be confused by gmail vs. googlemail. That's what you get for using non-Haskell software. ;)

7 13

[NL-FP 2016] Final CFP: Dutch Functional Programming Day 2016
by Atze Dijkstra 14 Dec '15

14 Dec '15

[My apologies for multiple received copies of the same message] Final Call for Participation: Dear all, The next Dutch Functional Programming day (NL-FP 2016) will be held on Friday, January 8, 2016 at the Utrecht University, The Netherlands. The program of the day now is online (see the below webpage). At the end of the day we will have a joint dinner. Besides the program, on the web page http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome <http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome> for the day you’ll also find the registration, which is by letting me know via email (with a subject header that begins with [NL-FP 2016]) whether you want to (1) participate, (2) join dinner, also see the webpage for additional details. There is still room for a demo or poster during lunch/break time. If you intend to participate, please let me know before the end of this year because we like to know how many people we can expect. Hope to meet you all in Utrecht at the next FP Day! Best regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze <http://www.cs.uu.nl/~atze> . /--| \ Fax : +31-30-2513971 .... | Email: atze(a)uu.nl <mailto:atze@uu.nl> ............... / |___\

1 0

Problem running the ping example from "Parallel and Concurrent Programming in Haskell"
by s nedunuri 13 Dec '15

13 Dec '15

hello I am trying out the examples in Chapter 14 of the book, and was able to install and build the parconc-examples package fine. However when I try running the (very first example) ping program I get the following error: ping.exe: bind: failed (Cannot assign requested address (WSAEADDRNOTAVAIL)) It appears that the failure is in the main function: distribMain (\_ -> master) Main.__remoteTable Any ideas? thanks PS I am running Haskell Platform 7.10.2-a on Windows 7

3 3

ANNOUNCE: bank-holidays-england: Calculation of bank holidays in England and Wales
by David Turner 12 Dec '15

12 Dec '15

Hi all, A very belated announcement of a little library that implements the frankly daft rules for calculating the dates of bank holidays in England and Wales. With apologies to the Welsh for the abbreviated package name, and to the Scots for not including yours too. http://hackage.haskell.org/package/bank-holidays-england Comments and feature requests are most welcome. Cheers, David

1 0

ANNOUNCE: alarmclock-0.2.0.8: wake up at a certain time
by David Turner 12 Dec '15

12 Dec '15

Hi all, A very belated announcement of a little library for efficiently waking up at a certain time. I've found this useful for things like timeouts, scheduling retries, cache expiry and so on. Not a lot to say, really, it does what it says on the tin! http://hackage.haskell.org/package/alarmclock Comments and feature requests are most welcome. Cheers, David

1 0

[ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
by Ben Gamari 11 Dec '15

11 Dec '15

Hello everyone, We are pleased to announce the release of GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3/ There can be found source tarballs and binary distributions for 64-bit and 32-bit modern Linux (GMP 5.0 or later), CentOS (GMP 4.0), Windows, and 64-bit Mac OS X platforms. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x97DB64AD). Significant fixes in release include changes to the simplifier's treatment of rules, the handling of Mac OS X frameworks, and support for response files to work around the restrictive command line length limit on Windows. As always, a full accounting of the changes present in this release can be found in the release notes [1]. The previous release, 7.10.2, was well-behaved save a couple notable bugs; while we have merged a good number of bug fixes in 7.10.3 they were were largely low risk and so we expect that this release should be similiarly stable. A notable exception is the upgrade of the Windows compiler toolchain to GCC 5.2. Typically we would refrain from making such large changes in a point release but Windows users have been long suffering at the hand of the old toolchain (e.g. lack of response file support, #8596, and lack of SEH support). We expect that this change should fix far more than breaks. Unfortunately, due to some oversights in the release process there are two source tarballs for this release. The first, ghc-7.10.3-src.tar.{bz2,xz}, does not include the release notes in the users guide. This is fixed in the second patchlevel release, ghc-7.10.3a-src.tar.{bz2,xz}. It is recommended that users wanting a source release use the ghc-7.10.3a-src tarballs. GHC 7.10.3 will very likely be the last release in the GHC 7 series. In the coming weeks we will be beginning the release process for GHC 8.0, which will include a number of exciting features including the merger of kinds with types, injective type families, imporved DWARF debugging information, applicative-do syntax, a Strict language extension synonyms mechanism, and more. See the GHC 8.0.1 status page for details [2]. Happy compiling! Cheers, - Ben [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-1… [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

11 14

Audio search library; and debugging help!
by Richard Lewis 11 Dec '15

11 Dec '15

Hi there, For a little while I've been working on an audio search library. It wraps over a C++ library written by some of my colleagues. It's nearing the state where someone other than me might actually be able to use it. So this message is partly an annoucement: <https://github.com/TransformingMusicology/libaudioDB-haskell> I'd be very interested to hear if anyone has a go at installing it and running the "tests". But this message is also a request for help, because I'm actually stuck with a bug. I've created a fork of the above repo here: <https://github.com/ironchicken/libaudioDB-haskell> which includes an extra commit which adds quite a few tracing statements. So if anyone feels up to trying to help me with my bug, then this would be the repo to use. The bug goes something like this: One of the features I need to implement is so-called "query rotation". The library implements audio feature searching. For some kinds of multi-dimensional audio features, it's useful to execute queries with them repeatedly moving the values between the dimensions each time to get a kind of exhaustive search. As a specific example (and for those who know a little music theory), there's a feature known as chroma which gives a measure of the signal energy in each of the 12 pitch classes for each window in the audio. If you search with a vector of chroma features, you will only find results that are at exactly the same pitch. But if you shift the chroma search vector around 11 times, you can effectively search for the query vector in every transposition (that's "transposition" as in to transpose in music theory). Anyway, I've tried to capture this in the library by allowing a call to the Sound.Audio.Database.Query.query function to include a QueryTransformer, which is essentially a function which takes a query and returns a new query. And then one instance of this is the function S.A.D.Query.mkSequenceQueryWithRotation which uses another helper function, S.A.D.Query.mkSequenceQueryMutateDatum. This function takes a Ptr to a query, and scribbles over the memory to replace its contents with an altered query vector: the result of some mutation function. Now, what originally alerted me to there being anything wrong with this was that, when I execute a rotated query, I'm getting exactly the same results as for a non-rotated query. As I started investigating, the first thing I found was that the altered feature vectors were not being altered in the way I expected. If I printed them and traced the path of a single value, it wasn't moving step-wise between the bins, but instead jumping around between them randomly. I eventually put in enough putStrLn and trace calls to find that, I think, each time the query is transformed, instead of doing just one transformation, it does as many transformations as times it has iterated: i.e., first iteration it does one transformation, second iteration it does two transformations, and so on. The recursive (sort of iterative?) query transformation is implemented in S.A.D.Query.queryWithTransformPtr. But I'm now at a loss to say whether there's anything actually wrong with this function. So, I think this is the end of my message. I appreciate that this is a very specific problem. I know it's normally helpful to try and abstract a problem into something in terms of Foos and Bars, but I'm not sure I can do this here. As a result, it would be a significant undertaking for anyone to try and help out. So I would be even more grateful than usual if anyone could! (And that's not really meant as a grovelling plea, it's actually more of a warning: you probably shouldn't try and help me.) Thanks, Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Richard Lewis Computing, Goldsmiths' College t: +44 (0)20 7078 5203 @: lewisrichard http://www.transforming-musicology.org/ 905C D796 12CD 4C6E CBFB 69DA EFCE DCDF 71D7 D455 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

1 1

Darcs Hacking Sprint #10 (January 15th-17th, Seville)
by Guillaume Hoffmann 10 Dec '15

10 Dec '15

Dear Hackers I'm glad to announce that the 10th Darcs Sprint that will be in Seville, on January 15-17 at the ETS de Ingeniería Informática, Universidad de Sevilla. Please check the details at: http://darcs.net/Sprints/2016-01 Here are three things to know 1. Everybody is welcome to join us. We'd love to have you, whatever your Haskell or Darcs hacking experience. Also, if you've got a wacky idea for the future of version control, or a cool use for the Darcs library, you should join us too :-) 2. Please let us know if you're attending: * add your name to http://wiki.darcs.net/Sprints/2016-01 * send me (privately) your full name and some official identification number for access to the university on Saturday and Sunday. 3. We can reimburse travel costs (within reason!). Let us know if you'd like a reimbursement, and save your receipts. Many thanks to everybody who participated in our fundraising drives or who gave money on the side. Thanks also to the Software Freedom Conservancy for making fundraising and reimbursements so painless! If you can't join us in person, but you'd like to cheer us on, say hello at http://darcs.net/Donations ! see you in one month! Guillaume

1 0

Looking for maintainers for emacs-haskell-tutorial
by Alejandro Serrano Mena 10 Dec '15

10 Dec '15

Dear Haskell-Café, Some time ago, and as part of my Google Summer of Code project, I wrote a tutorial about setting up Emacs to work with Haskell [ https://github.com/serras/emacs-haskell-tutorial/blob/master/tutorial.md] The tutorial is now a bit outdated and several issues are pending solution [ https://github.com/serras/emacs-haskell-tutorial/issues] However, due to other (young, crying) obligations I don't have the time needed to maintain the tutorial anymore, all by myself. Thus, I would like to ask whether somebody is willing to maintain the tutorial up-to-date, and take care of the issues. Or simply, whether somebody is willing to help in doing so. Regards, Alejandro

2 1

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

-Wall in IHaskell notebooks?
by David Banas 05 Dec '15

05 Dec '15

Does anyone know how to turn on “-Wall” in a IHaskell notebook?

2 6

Eq macro which matches anything
by frantisek kocun 05 Dec '15

05 Dec '15

Hi guys, I'm doing Write yourself Scheme tutorial. And for testing it would be cool to have some kind of macro. -- My data type with Eq derived data LispError = NumArgs Integer [LispVal] | TypeMismatch String LispVal | Parser ParseError | BadSpecialForm String LispVal | NotFunction String String | UnboundVar String String | Default String deriving (Eq) -- I can call == NumArgs 1 [] == NumArgs 1 [] -- but sometimes I want to do (I know I can implement my own Eq, but I want to use both forms) NumArgs 1 [] == NumArgs 1 _ where I omit second parameter. I think derived Eq where it matches all the args is fine I just need to do macro which will get whateverType by compiler and always return True in Equality check. Do you think it is possible to do? I use Mockito library in java but java is OO, so completely different beast. Thank you

3 2

Announcing Pinchot - builds data types and Earley grammars for context-free grammars
by Omari Norman 05 Dec '15

05 Dec '15

I have just uploaded to Hackage the Pinchot library: https://hackage.haskell.org/package/pinchot I also have a pull request to get it into Stackage so hopefully it should be there in a few days as well. Pinchot provides a simple monadic language that you use to describe a context-free grammar. Using this language you build a value that represents your grammar. Then, using this value and Template Haskell, you can automatically generate a complete set of data types that correspond to the rules in your context-free grammar. You also use Template Haskell to generate an Earley grammar for your language, using the Haskell Earley library: https://hackage.haskell.org/package/Earley Unlike parsers such as Parsec and Happy, Earley parses all context-free grammars, regardless of the amount of necessary look-ahead or the presence of left recursion. Earley does not, however, parse context-sensitive grammars. Pinchot is documented and comes with several examples. It passes several simple tests but it has not yet been used in anger. I wrote Pinchot because I was excited to see Earley when it was released. Finally we had a parser that would simply parse context-free grammars. Give a grammar, get a parser. Parsec and its ilk, on the other hand, are libraries allowing you to write a recursive-descent parser by hand. That's useful, but if you know you have a context-free grammar it's easier to use a tool tailored to that. So when using Earley I found myself writing the data types and then writing the Earley grammar specification. This was a rote process ripe for automation.

1 0

Reasoning about performance
by Joachim Durchholz 05 Dec '15

05 Dec '15

Hi all, is there an easy-to read introductory paper on reasoning about performance in Haskell? Stuff like big-Oh space and time complexity of a function. What I'm mostly after is how to organize complexity reasoning given non-strict evaluation. In that situation, a function's complexity depends on what subexpressions of the parameters have already been evaluated, so you get rather complicated conditional formulae, and you also need to somehow express what parts of a passed-in parameter may get evaluated under what conditions. Is there even a good notation for that kind of stuff? Is there advice on how to organize the code to make performance formulae manageable? Example: Performance of length xs Turns out it is the number of items in xs, plus whatever you need to evaluate the list spine, as far as the list spine elements have not yet been evaluated (but you do not need to evaluate the list items). I have no idea how to even write that down. What notation to use so one can formally reason about it. Any pointers? Regards, Jo

4 6

ANN: stack-0.1.10.0
by Emanuel Borsboom 05 Dec '15

05 Dec '15

Release notes: - The Stack home page is now at haskellstack.org, which shows the documentation rendered by readthedocs.org. Note: this has necessitated some changes to the links in the documentation’s markdown source code, so please check the links on the website before submitting a PR to fix them. - The locations of the Ubuntu <http://docs.haskellstack.org/en/stable/install_and_upgrade.html#ubuntu> and Debian <http://docs.haskellstack.org/en/stable/install_and_upgrade.html#debian> package repositories have changed to have correct URL semantics according to Debian’s guidelines #1378 <https://github.com/commercialhaskell/stack/issues/1378>. The old locations will continue to work for some months, but we suggest that you adjust your /etc/apt/sources.list.d/fpco.list to the new location to avoid future disruption. - openSUSE and SUSE Linux Enterprise <http://docs.haskellstack.org/en/stable/install_and_upgrade.html#opensuse-su…> packages are now available, thanks to @mimi1vx <https://github.com/mimi1vx>. Note: there will be some lag before these pick up new versions, as they are based on Stackage LTS. Major changes: - Support for building inside a Nix-shell providing system dependencies #1285 <https://github.com/commercialhaskell/stack/pull/1285> - Add optional GPG signing on stack upload --sign or with stack sig sign ... Other enhancements: - Print latest applicable version of packages on conflicts #508 <https://github.com/commercialhaskell/stack/issues/508> - Support for packages located in Mercurial repositories #1397 <https://github.com/commercialhaskell/stack/issues/1397> - Only run benchmarks specified as build targets #1412 <https://github.com/commercialhaskell/stack/issues/1412> - Support git-style executable fall-through (stack something executes stack-something if present) #1433 <https://github.com/commercialhaskell/stack/issues/1433> - GHCi now loads intermediate dependencies #584 <https://github.com/commercialhaskell/stack/issues/584> - --work-dir option for overriding .stack-work #1178 <https://github.com/commercialhaskell/stack/issues/1178> - Support detailed-0.9 tests #1429 <https://github.com/commercialhaskell/stack/issues/1429> - Docker: improved POSIX signal proxying to containers #547 <https://github.com/commercialhaskell/stack/issues/547> Bug fixes: - Show absolute paths in error messages in multi-package builds #1348 <https://github.com/commercialhaskell/stack/issues/1348> - Docker-built binaries and libraries in different path #911 <https://github.com/commercialhaskell/stack/issues/911> #1367 <https://github.com/commercialhaskell/stack/issues/1367> - Docker: --resolver argument didn’t effect selected image tag - GHCi: Spaces in filepaths caused module loading issues #1401 <https://github.com/commercialhaskell/stack/issues/1401> - GHCi: cpp-options in cabal files weren’t used #1419 <https://github.com/commercialhaskell/stack/issues/1419> - Benchmarks couldn’t be run independently of eachother #1412 <https://github.com/commercialhaskell/stack/issues/1412> - Send output of building setup to stderr #1410 <https://github.com/commercialhaskell/stack/issues/1410>

2 1

Creating an instance of the Show Typeclass for a datatype
by Murilo Winter 03 Dec '15

03 Dec '15

Hello, As part of my exercise, I have to create an instance of the show typeclass for a given data type defined as: 1. *type *stat *= (*String*, Int)* *If* it was a data type, like: 1. data TrafficLight = Red | Yellow | Green It would be as simple as doing: 1. instance Show TrafficLight where 2. show Red = "Red light" 3. show Yellow = "Yellow light" 4. show Green = "Green light" However, I do not know how to declare the instance for a type, and then how to access its elements (String and Int). This is what I have so far, which does not work: 1. instance Show Stat where 2. show stat(a,b) = a instance Show Stat where show stat(a b) = b (imagine, for example, I desire to write" the value of "String" is "Int"). Thanks,

3 2

Yet Another Named Record
by Dmitry Olshansky 03 Dec '15

03 Dec '15

Hello, cafe! I made a small library https://github.com/odr/pers. It is my attempt for Named Record problem. There is no TH, just TF, Symbols and so on. With this library one can now: * Construct record sequentially (record is balanced tuple-based tree): type T = "a":>Int +> "b":>String +> "c":>Maybe Int rec = V 5 +> V "b" +> V (Just 3) :: T * Get Lens' for fields or record (group of fields) with O(k*log n) access: lb = fieldLens (Proxy :: "b":>String) :: Lens' T String lca = recLens :: Lens' T ("c:>Maybe Int +> "a":>Int) Note that recLens is Projection! * Lift all fields into Functor: type LT = Lifted Maybe T -- LT == "a":>Maybe Int +> "b":>Maybe String +> "c":>Maybe (Maybe Int) If all fields has Default instances, record has it also. It is the case for Lifted Maybe T. * Convert from and to Map of fields (using PersistField and PersistValue from persistent package) m = M.fromList [ (someSymbolVal "a", toPersistValue 1) , (someSymbolVal "b", toPersistValue "xx") -- value for "c" is optional ] recEither = mapToRec (Proxy :: Proxy T) m :: Either [SomeSymbol] T m' = fmap toMap recEither I wonder: - Are there similar attempts? - Is it interesting? I suppose it could be used as basis for Persistent (instead of TH). Is it? Other application? - What other features you want to add here? Best regards, Dmitry Olshansky

1 0

[ANNOUNCE] An Argh! interpreter in wxHaskell
by Henk-Jan van Tuyl 03 Dec '15

03 Dec '15

L.S., I just updated and cabalized arghwxhaskell (which I found on SourceForge) and put it on Hackage. arghwxhaskell is an interpreter for the Argh! programming language in wxHaskell. Argh! is an esoteric programming language created by Sascha Wilde. Wiki page: https://wiki.haskell.org/Argh! Package address: https://hackage.haskell.org/package/arghwxhaskell Regards, Henk-Jan van Tuyl -- 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 --

1 0

[ANNOUNCE] Haskell DBMS: Project:M36
by A.M. 02 Dec '15

02 Dec '15

Hello, Project:M36 is an open-source, relational algebra engine database management system written in Haskell. When used as a backend with other Haskell frameworks such as yesod, Project:M36 completes a fully-Haskell application stack. https://github.com/agentm/project-m36 Project:M36 adheres strongly to the relational algebra principles laid out by Chris Date in his books and, thus, includes a TutorialD interactive interpreter for learning about the relational algebra. Thus, Project:M36 does not suffer from the typical type-system impedance mismatch or SQL inconsistencies common in ORMs. Of particular interest to Haskellers is the existentially-quantified value type which allows any Haskell data type adhering to a set of basic typeclasses to be used directly as a database value. This feature includes creating database functions to operate directly on these values. In addition, the transaction model is similar to git: instead of continually contending for the "latest committed" state, the DBMS maintains a transaction graph which allows for branching and time travel to past commits. Naturally, through the use of immutable data structures, Project:M36 opens the door for parallelization of every query. Project:M36 includes two native Haskell interfacing libraries: a) a driver for the "persistent" library and b) a client library which allows direct access to the relational algebra DSLs. Thanks for looking at Project:M36! Best regards, Team Project:M36

3 3

[ANNOUNCE] Haskell DBMS: Project:M36
by A.M. 02 Dec '15

02 Dec '15

Hello, Project:M36 is an open-source, relational algebra engine database management system written in Haskell. When used as a backend with other Haskell frameworks such as yesod, Project:M36 completes a fully-Haskell application stack. https://github.com/agentm/project-m36 Project:M36 adheres strongly to the relational algebra principles laid out by Chris Date in his books and, thus, includes a TutorialD interactive interpreter for learning about the relational algebra. Thus, Project:M36 does not suffer from the typical type-system impedance mismatch or SQL inconsistencies common in ORMs. Of particular interest to Haskellers is the existentially-quantified value type which allows any Haskell data type adhering to a set of basic typeclasses to be used directly as a database value. This feature includes creating database functions to operate directly on these values. In addition, the transaction model is similar to git: instead of continually contending for the "latest committed" state, the DBMS maintains a transaction graph which allows for branching and time travel to past commits. Naturally, through the use of immutable data structures, Project:M36 opens the door for parallelization of every query. Project:M36 includes two native Haskell interfacing libraries: a) a driver for the "persistent" library and b) a client library which allows direct access to the relational algebra DSLs. Thanks for looking at Project:M36! Best regards, Team Project:M36

1 0

Month (and a bit) in haskell-ide-engine November 2015
by Alan & Kim Zimmerman 02 Dec '15

02 Dec '15

Welcome Haskell IDE Engine (future) users, Haskell IDE Engine progress report for November 2015. What is Haskell IDE Engine? Not an IDE. It is a common point to join together the effort of integrating tools into an IDE and the effort of writing tools for an IDE, by providing an API in the middle that each of these parties can work from and to. Important developments The first commit to this project took place on 22 October. In a little over a month we have had 290 commits, 116 PRs, and 114 issues. We have 14 contributors, 16 forks, 155 stars and 36 watchers. So it is safe to say we are actively working on the project. At this point we have an initial implementation of the architecture, which allows for different front end transport implementations to interface with the IDE. The current supported transports are JSON over stdio and JSON over HTTP. The architecture allows for other data encodings or interface protocols, so long as the hie side can read and write to TChans. We have a PluginDescriptor type which captures information about a given plugin, which is loaded into the main dispatcher in a namespace per plugin. The commands exposed by a plugin can run in synchronous or async mode, if they are long running, or must coordinate with backend infrastructure. The initial plugins under development provide access to - ghc-mod - HaRe - base plugin, allowing plugin introspection - example plugin A ghci-ng plugin is on hold pending the Remote GHCi work Simon Marlow is doing. We have initial integrations to emacs, and to leksah. Current project focus The current project focus is on getting our collective heads straight on what actually needs to be done, and to provide working integrations to at least 2 IDEs to get a better feel for what is needed. Both of these are well in hand, and if anyone would like to join in the discussion happens via the github issue tracker and docs section of the project, as well as IRC at #haskell-ide-engine on freenode. Issues closed in November - Do plugins the same way as GHC #1 <https://github.com/haskell/haskell-ide-engine/issues/1> - Use Idris's protocol? #3 <https://github.com/haskell/haskell-ide-engine/issues/3> - What would the smallest useful haskell-ide look like #4 <https://github.com/haskell/haskell-ide-engine/issues/4> - Loose comments from editor (emacs) perspective #5 <https://github.com/haskell/haskell-ide-engine/issues/5> - Name of project module hierarchy root question #9 <https://github.com/haskell/haskell-ide-engine/issues/9> - Proposition: setup the same label and milestones system as in stack repo #22 <https://github.com/haskell/haskell-ide-engine/issues/22> - The command "./travis_long stack +RTS -N2 -RTS build --test --pedantic" exited with 1 #28 <https://github.com/haskell/haskell-ide-engine/issues/28> - Travis build should be deterministic #30 <https://github.com/haskell/haskell-ide-engine/issues/30> - HIE should start web server only on demand #31 <https://github.com/haskell/haskell-ide-engine/issues/31> - Make all ToJSON instances clearly visible #32 <https://github.com/haskell/haskell-ide-engine/issues/32> - make jsonHttpListener only start via a CLI flag #33 <https://github.com/haskell/haskell-ide-engine/issues/33> - Add the balance of commands to the HaRe plugin #36 <https://github.com/haskell/haskell-ide-engine/issues/36> - Extend the dispatcher to validate commands before calling worker #37 <https://github.com/haskell/haskell-ide-engine/issues/37> - Decide on package name for the plugin API / plugin packages #39 <https://github.com/haskell/haskell-ide-engine/issues/39> - Remove Context from IdeRequest #40 <https://github.com/haskell/haskell-ide-engine/issues/40> - Consume invalid input #43 <https://github.com/haskell/haskell-ide-engine/issues/43> - Encourage stateless programming style #45 <https://github.com/haskell/haskell-ide-engine/issues/45> - Worker function parameter passing #54 <https://github.com/haskell/haskell-ide-engine/issues/54> - Bring in async processing #67 <https://github.com/haskell/haskell-ide-engine/issues/67> - Define Emacs menu #68 <https://github.com/haskell/haskell-ide-engine/issues/68> - Add references to hsimport, hlint-refactor, haskdogs, etc. #84 <https://github.com/haskell/haskell-ide-engine/issues/84> - struggling with ghci-ng #86 <https://github.com/haskell/haskell-ide-engine/issues/86> - Different behavior between launch stack exec hie and hie directly #87 <https://github.com/haskell/haskell-ide-engine/issues/87> - PluginDescriptor should not be serialisable #92 <https://github.com/haskell/haskell-ide-engine/issues/92> - Add user visible info to PluginDescriptor #98 <https://github.com/haskell/haskell-ide-engine/issues/98> - Consider switching back to aeson-generated json serialization? #109 <https://github.com/haskell/haskell-ide-engine/issues/109> Pull requests merged in November - Fix badges #15 <https://github.com/haskell/haskell-ide-engine/pull/15> - Add argon to Tools #17 <https://github.com/haskell/haskell-ide-engine/pull/17> - (RFC) [list of tools] add more tools, add links, add short descriptions, group tools #18 <https://github.com/haskell/haskell-ide-engine/pull/18> - fixed typo #21 <https://github.com/haskell/haskell-ide-engine/pull/21> - [RFC] New readme for the project #23 <https://github.com/haskell/haskell-ide-engine/pull/23> - Fix spelling of ‘supersede’ in README #24 <https://github.com/haskell/haskell-ide-engine/pull/24> - Fix minor typos #26 <https://github.com/haskell/haskell-ide-engine/pull/26> - Add Emacs process communication layer #27 <https://github.com/haskell/haskell-ide-engine/pull/27> - Improve wire protocol #34 <https://github.com/haskell/haskell-ide-engine/pull/34> - Handwrite ToJSON instances, fix #32 #35 <https://github.com/haskell/haskell-ide-engine/pull/35> - Introduce cmdFileExtensions for the CommandDescriptor #41 <https://github.com/haskell/haskell-ide-engine/pull/41> - Make web interface optional and port configurable #42 <https://github.com/haskell/haskell-ide-engine/pull/42> - Remove Context, simplifying IdeRequest #44 <https://github.com/haskell/haskell-ide-engine/pull/44> - Implement testing framework for Emacs (plus some fixes) #46 <https://github.com/haskell/haskell-ide-engine/pull/46> - Remove state cwd #47 <https://github.com/haskell/haskell-ide-engine/pull/47> - Dispatcher validation #51 <https://github.com/haskell/haskell-ide-engine/pull/51> - Improve console #53 <https://github.com/haskell/haskell-ide-engine/pull/53> - Error structure with code #55 <https://github.com/haskell/haskell-ide-engine/pull/55> - Use a GADT parametrized by param type, fixes #54 #56 <https://github.com/haskell/haskell-ide-engine/pull/56> - Ghcmod commands #57 <https://github.com/haskell/haskell-ide-engine/pull/57> - Expect json input separated by STX, fix #43 #59 <https://github.com/haskell/haskell-ide-engine/pull/59> - fixed typo ParamDescription #60 <https://github.com/haskell/haskell-ide-engine/pull/60> - Add the rest of the commands to HaRe plugin #62 <https://github.com/haskell/haskell-ide-engine/pull/62> - Short cut sleeping when result is available #63 <https://github.com/haskell/haskell-ide-engine/pull/63> - Typed responses #64 <https://github.com/haskell/haskell-ide-engine/pull/64> - Enrich plugins call #65 <https://github.com/haskell/haskell-ide-engine/pull/65> - Implement STX #69 <https://github.com/haskell/haskell-ide-engine/pull/69> - Fall back to emacs if there is no emacs24 binary #70 <https://github.com/haskell/haskell-ide-engine/pull/70> - Async dispatch #72 <https://github.com/haskell/haskell-ide-engine/pull/72> - Remove invalid input even if not handled #73 <https://github.com/haskell/haskell-ide-engine/pull/73> - Handle end-of-file #74 <https://github.com/haskell/haskell-ide-engine/pull/74> - Properly handle STX delimited message #75 <https://github.com/haskell/haskell-ide-engine/pull/75> - [WIP] Initial stab at hie-mode #76 <https://github.com/haskell/haskell-ide-engine/pull/76> - Rename sub-packages to be hie-* #77 <https://github.com/haskell/haskell-ide-engine/pull/77> - added fast-tags #80 <https://github.com/haskell/haskell-ide-engine/pull/80> - Simplify json #85 <https://github.com/haskell/haskell-ide-engine/pull/85> - Support commands that only require a context #88 <https://github.com/haskell/haskell-ide-engine/pull/88> - Add plugin name to commandDetail response #90 <https://github.com/haskell/haskell-ide-engine/pull/90> - Ghc mod dir #91 <https://github.com/haskell/haskell-ide-engine/pull/91> - PluginDescriptor no longer serialisable. #93 <https://github.com/haskell/haskell-ide-engine/pull/93> - Adapt elisp to plugins response changes #94 <https://github.com/haskell/haskell-ide-engine/pull/94> - Json enhancements #96 <https://github.com/haskell/haskell-ide-engine/pull/96> - Use hierarchical menus instead of a flat one #97 <https://github.com/haskell/haskell-ide-engine/pull/97> - Create elisp functions for all commands #99 <https://github.com/haskell/haskell-ide-engine/pull/99> - Rename haskell-ide-engine to hie #100 <https://github.com/haskell/haskell-ide-engine/pull/100> - Update irc channel for travis #101 <https://github.com/haskell/haskell-ide-engine/pull/101> - Insert dash between plugin and command name #102 <https://github.com/haskell/haskell-ide-engine/pull/102> - Use dash.el #103 <https://github.com/haskell/haskell-ide-engine/pull/103> - nicer parameters and command return type #105 <https://github.com/haskell/haskell-ide-engine/pull/105> - Install dash.el for tests and require it #106 <https://github.com/haskell/haskell-ide-engine/pull/106> - docs: mention apply-refact, hsimport, haskdogs #110 <https://github.com/haskell/haskell-ide-engine/pull/110> - add ShortName and Overview to PluginDescriptor #111 <https://github.com/haskell/haskell-ide-engine/pull/111> - Extract the first type of a type info response #113 <https://github.com/haskell/haskell-ide-engine/pull/113> Contributors active in November Aaron Wolf, Alan Zimmerman, Daniel Bergey, Daniel Gröber, Gracjan Polak, JP Moresmau, Jochen Görtler, Joe Hillenbrand, Justin Wood, Michael Sloan, Moritz Kiefer, Rory O’Kane, Rémi Vion, jpmoresmau Thanks A special thanks to Gracjan Polak for running his report scripts on this repo. Contributing Haskell IDE Engine needs volunteers like any other open source project. For more information see: https://github.com/haskell/haskell-ide-engine Also drop by our IRC channel: #haskell-ide-engine at irc.freenode.net. Thanks! Alan

1 0

A new case for the pointed functor class
by roconnor＠theorem.ca 02 Dec '15

02 Dec '15

>From <http://r6research.livejournal.com/28338.html>: There has been some debate for some time as to whether there should be a superclass for Applicative with just the pure function should exist: -- Natural law: -- fmap f . pure = pure . f class Functor f => Pointed f where pure :: a -> f a The charge laid against this class is that there are no laws for this single function beyond the single law that is naturally implied. Compare this to a more reasonable class -- Natural laws: -- distRight . right . fmap f = fmap (right f) . distRight -- distRight . left f = fmap (left f) . distRight -- -- Other laws: -- 1. either absurd (fmap Right) = distRight :: Either Void (f a) -> f (Either Void a) -- 2. fmap assocL . distRight . right distRight . assocR = distRight :: Either (Either a b) (f c) -> f (Either (Either a b) c) -- where -- assocL :: Either a (Either b c) -> Either (Either a b) c -- assocL (Left a) = Left (Left a) -- assocL (Right (Left a)) = Left (Right a) -- assocL (Right (Right a)) = Right a -- assocR :: Either (Either a b) c -> Either a (Either b c) -- assocR (Left (Left a)) = Left a -- assocR (Left (Right a)) = Right (Left a) -- assocR (Right a) = Right (Right a) class Functor f => StrongSum f where distRight :: Either a (f b) -> f (Either a b) distLeft :: Either (f a) b -> f (Either a b) distLeft = fmap switch . distRight . switch where switch :: Either a b -> Either b a switch = Right ||| Left StrongSum is a honest class with two additional real laws in addition to its natural laws. No one would object to creating and using such a class. What if I told you that Pointed and StrongSum are in fact the same class? class Functor f => Pointed f where pure :: a -> f a pure = fmap (id ||| absurd) . distRight . Left distRight : Either a (f b) -> f (Either a b) distRight = either (fmap Left . pure) (fmap Right) Theorem 1. If we define pure, then the distRight automatically satisfies the 2 required laws. Proof. Law 1: either absurd (fmap Right) = { extensionality of absurd } either (fmap Left . pure) (fmap Right) = { definition in terms of pure } distRight :: Either Void (f a) -> f (Either Void a) Law 2: fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR = either (fmap Left . pure) (fmap Right) case 1: Right x fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Right x = fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Right (Right x) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (either (fmap Left . pure) (fmap Right) (Right x)) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (fmap Right x) = fmap assocL $ fmap Right (fmap Right x) = fmap (assocL . Right . Right) x = fmap Right x = either (fmap Left . pure) (fmap Right) $ Right x case 2: Left (Right x) fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Left (Right x) = fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Right (Left x) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (either (fmap Left . pure) (fmap Right) (Left x)) = fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (fmap Left (pure x)) = fmap assocL $ fmap Right (fmap Left (pure x)) = fmap (assocL . Right . Left) (pure x) = fmap (Left . Right) (pure x) = fmap Left . fmap Right . pure $ x = fmap Left . pure . Right $ x = fmap Left . pure $ Right x = either (fmap Left . pure) (fmap Right) $ Left (Right x) case 3: Left (Left x) fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Left (Left x) = fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Left x = fmap assocL . either (fmap Left . pure) (fmap Right) $ Left x = fmap assocL . fmap Left . pure $ x = fmap (assocL . Left) . pure $ x = fmap (Left . Left) . pure $ x = fmap Left . fmap Left . pure $ x = fmap Left . pure . Left $ x = fmap Left . pure $ Left x = either (fmap Left . pure) (fmap Right) $ Left (Left x) Theorem 2. If we define pure, then pure = fmap (id ||| absurd) . distRight . Left where distRight = either (fmap Left . pure) (fmap Right) Proof. fmap (id ||| absurd) . distRight . Left = fmap (id ||| absurd) . either (fmap Left . pure) (fmap Right) . Left = fmap (id ||| absurd) . fmap Left . pure = fmap ((id ||| absurd) . Left) . pure = fmap id . pure = pure Theorem 3. If we define distRight such that distRight satisfies its two laws then distRight = either (fmap Left . pure) (fmap Right) where pure = fmap (id ||| absurd) . distRight . Left. Proof. either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) = distRight case 1: Left x either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) $ Left x = fmap Left . fmap (id ||| absurd) . distRight $ Left x = fmap (Left . (id ||| absurd)) $ distRight (Left x) = fmap (Left ||| (Left . absurd)) $ distRight (Left x) = fmap (Left ||| absurd) $ distRight (Left x) = { extensionality of absurd } fmap (Left ||| Right) $ distRight (Left x) = fmap id $ distRight (Left x) = distRight (Left x) case 2: Right x either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) $ Right x = fmap Right x = fmap (left absurd . Right) x = fmap (left absurd) $ fmap Right x = fmap (left absurd) . either absurd (fmap Right) $ Right x = { Law 1 for distRight } fmap (left absurd) . distRight $ Right x = { Natural law for distRight } distRight . left absurd $ Right x = distRight $ Right x Interestingly we only ever used the first law for distRight. By composing these proofs together we should be able to show that the second law for distRight holds whenever the first law does. In conclusion we have seen that the StrongSum class and the Pointed class are equivalent classes. The pure function contains the heart of what a law abiding distRight function is, such that whenever we have a law abiding distRight function it can be written in terms of pure and every instance of pure yields a law abiding distRight function. Given that I think people would welcome a StrongSum class, it only makes sense to equally welcome the Pointed class. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

2 1

Monadic function fails as Nothing in Maybe context but as Exception in Either context.
by Jeffrey Brown 01 Dec '15

01 Dec '15

I've written a monadic function which in a Maybe context produces a Nothing when it fails (as intended), but in an Either context produces an Exception rather than a Left. Here's a tiny demonstration. "tinyGraph" below has one Node, 0, with the label "dog". If I try to change the label at Node 0 to "cat", it works. If I try to change the label at Node 1 to "cat", it fails, because Node 1 is not in the graph. type MyGraph = Gr String String tinyGraph = mkGraph [(0, "dog")] [] :: MyGraph maybeSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Maybe MyGraph -- == Just (mkGraph [(0,"cat")] []) maybeFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Maybe MyGraph -- == Nothing eitherSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Either String MyGraph -- == Right (mkGraph [(0,"cat")] []) eitherFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Either String MyGraph -- *** Exception: Node not in Graph Here's the code: import Data.Graph.Inductive -- FGL, the Functional Graph Library gelemM :: (Monad m) => MyGraph -> Node -> m () gelemM g n = if gelem n g -- FGL's gelem function returns then return () -- True if the node is in the graph else fail "Node not in Graph" -- False otherwise replaceStringAtNode :: MyGraph -> Node -> String -> MyGraph replaceStringAtNode g n e = let (Just (a,b,c,d),g') = match n g in (a,b,e,d) & g' replaceStringAtNodeM :: (Monad m) => MyGraph -> Node -> String -> m MyGraph replaceStringAtNodeM g n s = do gelemM g n return $ replaceStringAtNode g n s -- if evaluated, the pattern match in replaceStringAtNode must succeed, -- because gelemM catches the case where n is not in the graph [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/test… -- Jeffrey Benjamin Brown

5 10

[ANN] clang-pure-0.1.0.0: Pure C++ code analysis
by Patrick Chilton 01 Dec '15

01 Dec '15

Hi everyone, I've been working on a pure binding to libclang that lets you easily analyze any code that the Clang compiler understands. Github: https://github.com/chpatrick/clang-pure Hackage: http://hackage.haskell.org/package/clang-pure Haddock: http://chpatrick.github.io/clang-pure/ libclang documentation: http://clang.llvm.org/doxygen/group__CINDEX.html A short example that prints out the type of every function in a header file (very useful for binding generation): main = do idx <- createIndex tu <- parseTranslationUnit idx "foo.h" [] let root = translationUnitCursor tu funDecs = root ^.. cosmosOf cursorChildrenF . filtered (\c -> cursorKind c == FunctionDecl) . folding (\c -> fmap (\t -> ( cursorSpelling c, typeSpelling t )) (cursorType c)) for_ funDecs $ \(f, t) -> putStrLn $ BS.unpack f ++ " :: " ++ BS.unpack t Or to find the number of gotos: gotoCount = lengthOf (cosmosOf cursorChildrenF . filtered (\c -> cursorKind c == GotoStmt)) root (This uses lens, but the library itself only has one optional lens-style function). Please refer to libclang's good documentation for an explanation of the functions. The only thing to keep in mind is that functions clang_foo are renamed to just foo, functions clang_getBar are renamed to just bar, and types CXBaz are renamed to just Baz in the Haskell bindings. Under the hood, a reference counting system ensures that the C objects are freed at the right time and in the right order, which allows the public API to be simple and pure. The bindings are not yet complete, so if you find something missing please make an issue or better yet send a pull request. :) Patrick

1 0

Month in Haskell Mode November 2015
by Gracjan Polak 01 Dec '15

01 Dec '15

Welcome Haskell Mode users, Haskell Mode progress report for November 2015 (online version <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…> ). For previous issue see October 2015 <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-…> . Go to Reddit discussion <https://www.reddit.com/r/haskell/comments/3uz7jl/month_in_haskell_mode_nove…> . <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>What is Haskell Mode? Haskell Mode is an umbrella project for multiple Emacs tools for efficient Haskell development. Haskell Mode is an open source project developed by a group of volunteers. For more information see https://github.com/haskell/haskell-mode. <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Important developments The bug that everybody was waiting for <https://github.com/haskell/haskell-mode/issues/962> was fixed! No more 'Illegal token' in indentation. Rejoice! <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Coming release In the beginning of December we plan to tag new stable release of haskell-mode with current state of the repo (plus possible bugfixes). <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Competitive projects Haskell editor landscape is growing and there are compelling propositions all over the place: - Atom IDE-Haskell <https://atom.io/packages/ide-haskell> - Haskell Vim IDE <https://github.com/begriffs/haskell-vim-now> - Leksah - Haskell IDE in Haskell <http://leksah.org/> - Haskell for Mac <http://haskellformac.com/> There is an idea turning into reality that there should be a common infrastructure powering all of the above. It is brewing in Haskell IDE Engine <https://github.com/haskell/haskell-ide-engine> repo. <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Cruft removal, reminder Last month we declared that we plan to remove some cruft. Note that SCC functions got salvaged and now they are fully functional part of haskell-mode! Killing list for December: - Remove haskell-bot.el <https://github.com/haskell/haskell-mode/pull/960> - Remove horizontal whitespace based smart indentation mode haskell-simple-indent <https://github.com/haskell/haskell-mode/pull/958> - Remove Unicode input method <https://github.com/haskell/haskell-mode/pull/939> - Remove haskell-checkers.el <https://github.com/haskell/haskell-mode/pull/959> <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Current project focus Current project focus is to lower entry barrier for newcomers by defining bite-sized tasks. Get 50 'well-defined-tasks' done as by the metric: https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-de… A 'well-defined-task' is a category of tasks that have the field cleared for them, questions already sorted out and detailed information how to get them done. So you can just sit, search for 'well-defined-task' label and enjoy the coding! The point is to lower the entry barrier for new users, new issue reporters and advanced programmers but Emacs lisp beginners to contribute to the project. Current status: 14 well-defined-tasks closed <https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-de…> plus 13 more open <https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-de…> . If only you can help with reaching our targets please do so! <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Issues closed in November - Repl hanging #447 <https://github.com/haskell/haskell-mode/issues/447> - On opening a file, haskell-doc opens several files defined in import section #742 <https://github.com/haskell/haskell-mode/issues/742> - Indentation has been spoiled #782 <https://github.com/haskell/haskell-mode/issues/782> - Refactor load-or-reload #807 <https://github.com/haskell/haskell-mode/issues/807> - Make import sorting/aligning optional #914 <https://github.com/haskell/haskell-mode/issues/914> - Remove possibility of 'Illegal token' from haskell-indentation #962 <https://github.com/haskell/haskell-mode/issues/962> - Can't edit a buffer while resolving merge conflict because Invalid Token error. #969 <https://github.com/haskell/haskell-mode/issues/969> - C pragma and Illegal token: else #970 <https://github.com/haskell/haskell-mode/issues/970> - Please do not make haskell-mode non-useful without ghc-mod #974 <https://github.com/haskell/haskell-mode/issues/974> - haskell-process-load-file: cabal test-suite wants to inject deps into library #979 <https://github.com/haskell/haskell-mode/issues/979> - Parsing failure with type-level lists #982 <https://github.com/haskell/haskell-mode/issues/982> - Stop blocking me from typing my code #985 <https://github.com/haskell/haskell-mode/issues/985> - haskell-process-do-type truncates types too aggressively #988 <https://github.com/haskell/haskell-mode/issues/988> - Code duplication between haskell-process-do-type, haskell-process-insert-type #989 <https://github.com/haskell/haskell-mode/issues/989> - Issues trying to use local version of a package in a layer #993 <https://github.com/haskell/haskell-mode/issues/993> - Emacs haskell-mode: how to send PART of file to repl? #1002 <https://github.com/haskell/haskell-mode/issues/1002> - haskell-process-load-file error (wrong-type-argument number-or-marker-p nil) when code has an error #1004 <https://github.com/haskell/haskell-mode/issues/1004> <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Pull requests merged in November - Add haskell-font-lock-tests.el. #957 <https://github.com/haskell/haskell-mode/pull/957> - [Doc] Add stack related configuration for compilation #971 <https://github.com/haskell/haskell-mode/pull/971> - Extract hoogle/hayoo code into haskell-hoogle.el and tidy up #973 <https://github.com/haskell/haskell-mode/pull/973> - Move some docs from wiki to manual #976 <https://github.com/haskell/haskell-mode/pull/976> - Don't spuriously modify tags-table-list's global value #978 <https://github.com/haskell/haskell-mode/pull/978> - Add an additional trigger for pragma suggestions #983 <https://github.com/haskell/haskell-mode/pull/983> - Add hayoo choice as part of hoogle url. #984 <https://github.com/haskell/haskell-mode/pull/984> - Clean up SCC code #986 <https://github.com/haskell/haskell-mode/pull/986> - Truncate multi-line messages less aggressively #990 <https://github.com/haskell/haskell-mode/pull/990> - Spelling #991 <https://github.com/haskell/haskell-mode/pull/991> - Use haskell-process-load-file, not -load-or-reload #992 <https://github.com/haskell/haskell-mode/pull/992> - Add RET, TAB and BACKTAB tests #994 <https://github.com/haskell/haskell-mode/pull/994> - Add case for haskell-debug-parse-module regex to parse #995 <https://github.com/haskell/haskell-mode/pull/995> - Remove duplicate filename in Makefile #996 <https://github.com/haskell/haskell-mode/pull/996> - Remove haskell-indentation-parse-error #997 <https://github.com/haskell/haskell-mode/pull/997> - Fix markup typo in README.md #999 <https://github.com/haskell/haskell-mode/pull/999> - Remove haskell-indentation-parse-error, fixup #1001 <https://github.com/haskell/haskell-mode/pull/1001> - Do not sort imports twice #1003 <https://github.com/haskell/haskell-mode/pull/1003> <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…>Contributors active in November Cody Goodman, Daniel Bergey, Gabor Greif, Gracjan Polak, Moritz Kiefer, Sibi Prabakaran, Steve Purcell, Thien-Thi Nguyen <https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-November…> Contributing Haskell Mode needs volunteers like any other open source project. For more information see: https://github.com/haskell/haskell-mode/wiki Also drop by our IRC channel: #haskell-emacs at irc.freenode.net. Thanks!

1 0

[ANN] dejafu-0.2.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency.
by Michael Walker 01 Dec '15

01 Dec '15

Hi cafe, I am happy to announce a new release of Déjà Fu, my library for testing concurrent Haskell programs! Things have advanced significantly since the paper I presented at the Haskell Symposium this year, both in terms of performance and functionality. Git: https://github.com/barrucadu/dejafu Hackage: https://hackage.haskell.org/package/dejafu-0.2.0.0 ## What is it? Déjà Fu is a library for developing and testing concurrent Haskell programs, it provides a typeclass-abstraction over GHC's regular concurrency API, allowing the concrete implementation to be swapped out. Why do we need this? Well, concurrency is really hard to get right. Empirical studies have found that many real-world concurrency bugs can be exhibited with small test cases using as few as two threads: so it’s not just big concurrent programs that are hard, small ones are too. We as programmers just don’t seem to have a very good intuition for traditional threads-and-shared-memory-style concurrency. The typical approach to testing concurrent programs is to just run them lots of times, but that doesn’t provide any hard coverage guarantees, and then we need to wonder: how many runs do we need? Fortunately, there has been a lot of research into testing concurrency in the past several years. Systematic concurrency testing is an approach where the source of nondeterminism, the actual scheduler, is swapped out for one under the control of the testing framework. This allows possible schedules to be systematically explored, giving real coverage guarantees for our tests. This is a library implementing systematic concurrency testing. It provides two typeclasses, MonadConc to abstract over much of Control.Concurrent and related modules, and MonadSTM, to similarly abstract over Control.Monad.STM. For examples, see the test suite and the async-dejafu source: - https://github.com/barrucadu/dejafu/tree/master/dejafu-tests - https://github.com/barrucadu/dejafu/tree/master/async-dejafu If you want to read more: - Recent technical report: http://misc.barrucadu.co.uk/pub/dejafu-techreport.pdf - Haskell Symposium paper about version 0.1.0.0: http://www.barrucadu.co.uk/publications/dejafu-hs15.pdf - A slew of things on my blog: http://www.barrucadu.co.uk/posts.html ## Changelog New stuff: - Relaxed memory: CRefs now behave just like IORefs, and testing can use one of three different memory models: sequential consistency, total store order (the default), and partial store order. - Support for 'yield'. - Integration with HUnit and tasty: https://hackage.haskell.org/package/hunit-dejafu https://hackage.haskell.org/package/tasty-dejafu - Version of the async library reimplemented to use MonadConc: https://hackage.haskell.org/package/async-dejafu - Fair bounding: which allows yield-based constructs like spinlocks to be tested without causing infinitely-long executions. - Length bounding: which allows for potentially non-terminating computations to be tested. Improvements: - Now uses partial-order reduction to cut down on the number of schedules to try, which is a *huge* improvement over just pre-emption bounding, which is what 0.1.0.0 did. - The 'autocheck' function has prettier output. ## How to use it: If you’re not making use of any IO in your code other than for concurrency, the transition to using MonadConc and MonadSTM will probably just be a textual substitution: - IO is replaced with MonadConc m => m - STM with MonadSTM m => m - *IORef with *CRef - *MVar with *CVar - *TVar with *CTVar - Most other things have the same name, and so can be replaced by just swapping imports around. If you are using other IO, you will need a gentle sprinkling of MonadIO and liftIO in your code as well. ## Is this really just a drop-in replacement for IO/STM? That’s the idea, yes. More specifically, the IO instance of MonadConc and the STM instance of MonadSTM just use the regular IO and STM functions, and so should have no noticeable change in behaviour. There are some differences which can lead to incorrect results when testing, but which should not affect code when used in an IO or STM context. Specifically: Control.Monad.Conc.Class.getNumCapabilities can lie to encourage more concurrency when testing; and Control.Exception.catch can catch exceptions from pure code, but Control.Monad.Conc.Class.catch can’t (except for the IO instance). -- Michael Walker (http://www.barrucadu.co.uk)

1 0

Fwd: Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Paolo Giarrusso 30 Nov '15

30 Nov '15

On 29 November 2015 at 20:12, Michael Orlitzky <michael(a)orlitzky.com> wrote: > On 11/29/2015 01:37 PM, Omari Norman wrote: >> >> Distribution packagers are savvy enough to use stack. > > Ignoring the question of *how* that might work, most distributions > forbid bundled dependencies because it creates a maintenance nightmare > and fills our users' machines with untraceable security vulnerabilities. But doesn't Haskell do static linking (usually) and cross-module inlining? Or are you fine with static linking as long as it's somehow tracked by the package manager, so that upgrading some-vuln-lib from 1.0 to 1.1 forces upgrading all client programs (looks quite doable at least with Debian packages)? -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

4 4

Fwd: Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Sven Panne 30 Nov '15

30 Nov '15

[... and now to the whole list, I hate gmail's defaults... :-] ---------- Forwarded message ---------- From: Sven Panne <svenpanne(a)gmail.com> Date: 2015-11-29 21:12 GMT+01:00 Subject: Re: [Haskell-cafe] Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack` To: Imants Cekusins <imantc(a)gmail.com> 2015-11-29 20:52 GMT+01:00 Imants Cekusins <imantc(a)gmail.com>: > [...] What if the top package (in namespace) contained major version? > > E.g. Cabal_1_22 > > below packages might use minor versions - basically, whenever api changes, > change the version part of the affected package. [...] > As a developer, what should I import if my program/library works with e.g. the version range [1.20 .. 1.23]? It definitely can't be import Cabal_1_23.Foo.Bar because if it later still works with e.g. 1.24, I would have to rename all my imports. And always using the lower bound is probably too restrictive, unless I'm mistaken... In general I think it's a bad idea to spread build dependencies all over the code. Cheers, S.

3 6

make a server & connect to it - strange behavior
by Patrick Redmond 30 Nov '15

30 Nov '15

Hi Haskell Cafe, When I start a web server (http-server:Network.HTTP.Server.serverWith) on a separate thread (async:Control.Concurrent.Async.withAsync) and then try to retrieve a response from the server (HTTP:Network.Browser.*) on a threaded runtime, I see either - connection refusals or - deadlock. Before I sink time into reading the source of the packages in question, does anybody see what's wrong with the code below? Increasing the timeout to wait for the server to initialize doesn't solve the problem. Using a bound thread doesn't solve the problem. I'm compiling with options "-threaded -rtsopts -with-rtsopts=-N". Thank you for taking a look. --Patrick This test project is on github. <https://github.com/plredmond/http-server-test-hs/blob/master/src/Lib.hs> module Lib ( someFunc ) where import Control.Monad.IO.Class (liftIO) import qualified Control.Concurrent as Concurrent import qualified Control.Concurrent.Async as Async import qualified Control.Exception as Exception import qualified Data.Maybe as Maybe import qualified Network.Browser as Browser import qualified Network.HTTP as HTTP import qualified Network.HTTP.Server as Server import qualified Network.HTTP.Server.Logger as ServerL import qualified Network.HTTP.Server.Response as ServerR import qualified Network.URI as URI someFunc :: IO (Either Exception.SomeException (URI.URI, HTTP.Response String)) someFunc = do Async.withAsync (Server.serverWith config handler) $ \_ -> do Concurrent.threadDelay . round $ 2e6 Exception.try . Browser.browse . Browser.request . Browser.defaultGETRequest $ uri where uri = Maybe.fromJust . URI.parseURI $ "http://localhost:8080/" config = Server.Config ServerL.stdLogger "localhost" 8080 handler _ url req = return (ServerR.respond ServerR.OK :: Server.Response String)

1 1

Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Omari Norman 29 Nov '15

29 Nov '15

On Sun, Nov 29, 2015 at 6:54 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com> wrote: > Hi all, > > IIUC, people used to spend nontrivial effort making their Haskell tools > work across a range of dependencies, and be careful about dropping support > for older ones. > Given the tools we had, this was not easy. I was never aware of any tool that substantially helped with making sure that a package remained compatible with the range of packages that was theoretically allowed by the package's .cabal file. > Do cabal sandboxes or Stack reduce that need, at least for applications?* > Or conversely, how bad is it to restrict support to users having them? I > guess I am asking about common policies, but this probably depends on > adoption of those tools. > > IMO there is really no one right answer to this question. It depends on how nice you are, or whether someone is paying you. Obviously if someone is paying you, do as she says or do what she needs. If no one is paying you, then how nice do you want to be by expending the work? Honestly I'm not very nice. I keep stuff working in the current Stackage Nightly but that's it. Maintaining compatibility with huge dependency matrices is just an enormous amount of work. In my view, someone installing an application can just use stack and Stackage.

6 10

Semi-closed handles and I/O errors: misleading documentation?
by Daniel Díaz 29 Nov '15

29 Nov '15

In the documentation for System.IO <http://hackage.haskell.org/package/base-4.8.1.0/docs/System-IO.html>, we find the following assertion: Any I/O errors encountered while a handle is semi-closed are simply discarded. also this other one: Encoding and decoding errors are always detected and reported, except during lazy I/O (hGetContents, getContents, and readFile), where a decoding error merely results in termination of the character stream, as with other I/O errors. Is this really correct, though? This SO question <http://stackoverflow.com/questions/16257037/detecting-i-o-exceptions-in-a-l…> says that exceptions found during lazy I/O are thrown from pure code, and a small experiment <http://stackoverflow.com/a/33985047/1364288> seems to confirm it. I personally prefer that behaviour, by the way. Perhaps the documentation should be updated?

1 0

Re: [Haskell-cafe] Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Paolo Giarrusso 29 Nov '15

29 Nov '15

On Sunday, November 29, 2015 at 1:23:58 PM UTC+1, Michael Snoyman wrote: > > For your particular example, you can use the transformers-compat package. > Thanks, that's useful! But to answer your general question: for applications, I strongly advocate > supporting just a single set of package version combos for dependencies. > Stack does do this by default, but cabal freeze files can get you most of > the way there too (barring some corner cases with different OSes and > OS-specific packages). > > I'm sure others will disagree with this recommendation, but I see no > reason to absorb a large amount of compatibility work just so that two > installations of the same application may end up behaving differently at > runtime because of differences in the behavior of a dependency. > Personally, I switched all the way to stack. I added mention of cabal sandboxes to address anybody who didn't switch yet or who prefers to stick to cabal.

1 0

Compatibility etiquette for apps, with cabal sandboxes and `stack`
by Paolo Giarrusso 29 Nov '15

29 Nov '15

Hi all, IIUC, people used to spend nontrivial effort making their Haskell tools work across a range of dependencies, and be careful about dropping support for older ones. Do cabal sandboxes or Stack reduce that need, at least for applications?* Or conversely, how bad is it to restrict support to users having them? I guess I am asking about common policies, but this probably depends on adoption of those tools. As in: a) without sandboxes or Stack, packages need to build with whatever environment is there. b) with either of sandboxes or Stack, you can just specify the environment and get it. With Stack, you can even specify whichever (supported) GHC you want, without impacting the environment. Concretely, Control.Monad.Trans.Error is deprecated in transformers-0.4.3.0, but the replacement Control.Monad.Trans.Except does not exist in transformers-0.3.x, thus in the one-but-last Haskell Platform (2014.2.0.0). Hence, fixing the deprecation would make this application hard to install** for some users, including past me (around two months ago).*** Would you apply such a patch? Would you keep it out? Or would you even use CPP (something I'd really like to avoid)? Cheers, Paolo * I take for granted libraries are a different matter — composing libraries means intersecting their supported versions. ** I'll omit detailing "hard to install", because that's a matter of opinion; I considered `constraint: transformers installed` necessary in my cabal config (https://www.vex.net/~trebla/haskell/cabal-cabal.xhtml) and I've read that's becoming the default in the HP, so I think users are entitled to this opinion. *** This particular app has a tiny userbase, so my question is a curiosity.

2 1

How to create a Wiki account?
by Jeffrey Brown 29 Nov '15

29 Nov '15

This [1] is as close as I can seem to get. I noticed [2] had obsolete information; it says Either is not by default a Monad. [1] https://wiki.haskell.org/HaskellWiki:New_accounts [2] https://wiki.haskell.org/Failure -- Jeffrey Benjamin Brown

3 2

Why was this function that fast ?
by Romain Gehrig 28 Nov '15

28 Nov '15

Hi, I implemented a function to count how many steps it takes for a number to be reduced to 1 using the Collatz Conjecture (also known as the 3n + 1 problem) and I was very surprised to see it working instantaneously for integers as big as 10^100000. The said function: collatzSteps :: Integer -> Integer collatzSteps n = steps 1 n where steps acc 1 = acc steps acc n' | even n' = steps (acc+1) (n' `div` 2) steps acc n' = steps (acc+1) (n' * 3 + 1) You can try in GHCi (apparently with an upper limit of 10^199669): GHCi> collatzSteps 10^199668 [big num...] GHCi> length $ show $ collatzSteps 10^199668 168740 GHCi> collatzSteps 10^199669 -- Oops [1] 36128 bus error ghci Notice the number 168740: it is the number of *digits* for the number of steps. It implies that the `acc` is ~= *10^168740* when the function ends. Without optimisation at some point, it would mean there were as much (acc+1) calls ! My understanding completely stops there; I can't comprehend why a function that shouldn't return anything even long after the end of the universe just finished before my eyes. Can someone shed some light on how this peculiar function was optimised by GHC? Many thanks, (still dazed) Romain

3 2

Info about List with terminal element
by Silvio Frischknecht 26 Nov '15

26 Nov '15

Hello, I'm interested in learning more about a list-like structure with a terminal element. I.e. data List t e = Cons e (List t e) | Null t or maybe data List t e = Cons e (List t e) | Null | Terminal t An practical application could be lazy reading from a file readFile :: String -> List Error String Obviously there is a Functor instance. There is even a Monad instance. However, it is not defined as obviously because it's not clear what the terminal element should be. There is a straight forward fold like structure. My questions are. Are there more interesting generalizations of List? What rules do they follow? How should the Monad work? Why? I know this is related to the whole Iteratee discussion (I'm not completely familiar with it). Cheers Silvio

5 10

Could not deduce Monad m => MonadReader r (ReaderT r m) ??
by David Turner 26 Nov '15

26 Nov '15

Porting some code from GHC 7.8.4 to GHC 7.10.2 and have encountered this rather odd failure: Could not deduce (MonadReader (PqColumn m -> m B.ByteString) (ReaderT (PqColumn m -> m B.ByteString) m)) arising from a use of ‘ask’ from the context (Monad m) bound by the type signature for readFieldByteString :: Monad m => PqColumn m -> RowReader m B.ByteString at src/EventStore/LibPq.hs:164:24-72 In a stmt of a 'do' block: readField <- ask In the expression: do { readField <- ask; lift $ readField col } In an equation for ‘readFieldByteString’: readFieldByteString col = do { readField <- ask; lift $ readField col } I wondered if it was because the environment type (PqColumn m -> m B.ByteString) itself was an instance of MonadReader and the typechecker was getting confused, so I put the environment in a newtype and it was indeed happy. Unfortunately I can't share enough of this code to get the problematic fragment to compile, and my initial attempts at a small reproduction have been unsuccessful. It's something like the following, but this compiles just fine. class MyClass m where type MyType m defaultValue :: m (MyType m) l :: Monad m => MyType m -> ReaderT (MyType m -> m Int) m Int l n = do f <- ask lift $ f n Before I put more effort into reproducing this, does anyone recognise this failure or know what might be going on here? Cheers, David

1 0

Re: [Haskell-cafe] Type-level lazy bool operations
by Oleg 26 Nov '15

26 Nov '15

Dmitry Olshansky wrote: > There are some type-level boolean operation (If, &&, ||, Not) in > Data.Type.Bool. Are they lazy enough? > > I faced with problem and it seems that the reason is non-lazy "If". > I.e. both (on-True and on-False) types are trying to be calculated. > Does it work in this way really? Could it be changed? Just a remark: if (type-level) computations are pure, then whether they are done lazily or in any other way should not matter. The evaluation strategy invariance is the main characteristic, if not the definition, of purity. Type-level computations are not pure however: they may have an effect of divergence, or generating a type-error. Thus we really need a type-level If, which evaluates only one of the two conditional branches but never both. It can be easily implemented using the standard approach of delaying evaluation with a thunk. Please see http://okmij.org/ftp/Haskell/TTypeable/TTypeable.hs and search for ORELSE (near the end of the file). See http://okmij.org/ftp/Haskell/typeEQ.html#TTypeable for background.

2 2

regex-posix broken on 64 bit windows.
by Gershom B 26 Nov '15

26 Nov '15

Here’s a ticket reporting the issue: https://github.com/haskell/haskell-platform/issues/144 The ticket is on the platform site, but it doesn’t really belong there. On the other hand, there’s no tracker for regex-posix anywhere else. This problem has probably existed for a _long_ time, and I guess has to do with 64-bit incompatibilities in the cbits shipped with the package. I’ve cc’d Chris Kuklewicz as he is author and maintainer. But I know that he has taken a step back from these packages some time ago. Generally, I would be happy to consider them stable-ish and let the community just migrate away from them or not as open source typically evolves. But regex-posix is pretty widely used still and is in the platform, so I think it is unfortunate that it is broken in this way. It would be great if some interested volunteer were to step up and fix this issue and maybe even offer to take over maintainership (to which I’m sure Chris would have no objection?). (Relatedly, it would be good to have a future discussion on which regex library, if any, is suitable for inclusion in the platform. At this point my inclination would be regex-tdfa-text, although my sense is nearly all the libs are relatively unmaintained at this point?) —Gershom

1 0

[ANN] Linode package
by Sebastian 25 Nov '15

25 Nov '15

Hello everybody, I'm happy to announce the initial release of the Linode package. It contains bindings to the Linode API and a few user friendly routines to setup and destroy VPS instances. The next major release will cover private IPs and load balancing. Hackage: http://hackage.haskell.org/package/linode Github: https://github.com/Helkafen/haskell-linode A working example is provided in the docs. It creates one linode instance and performs a dummy install: https://hackage.haskell.org/package/linode-0.1.0.4/docs/Network-Linode.html Use cases include: - Running some daily batch, with one or several instances - Dynamically adding some resources to a long running process - Anything you would normally do with a VPS Ideas, contributions and feedback are welcome! -- Sebastian de Bellefon

2 1