November 2015 - Libraries

On parsing Haskell and CPP
by Gershom B 23 Nov '15

23 Nov '15

We've had quite a bit of discussion lately on the difficulty in performing automated processing of Haskell files in the presence of CPP. It turns out that folks have tackled this sort of problem in the world of C, and done some interesting work. I recently ran across SuperC [1], part of the xtc [2] project. In the setting of C they have achieved some impressive results, including as I understand it, the ability to handle the entire Linux kernel across all CPP-recognized configurations. They note that this is a rather tedious to implement task, even once one has recognized the specification of how to do so. However, the paper is good at reviewing related work and simpler techniques as well, and perhaps among them there is a "good enough" set for the CPP used in common Haskell libraries? Cheers, Gershom [1] https://cs.nyu.edu/rgrimm/papers/pldi12.pdf [2] http://cs.nyu.edu/xtc/

1 0

Re: [Coq-Club] ANN: linearscan, linearscan-hoopl 1.0.0
by John Wiegley 21 Nov '15

21 Nov '15

>>>>> Beta Ziliani <bziliani(a)famaf.unc.edu.ar> writes: > I'd be interested to know what was the outcome of the project from the point > of view of BEA Systems. Is there any report about it? >From BAE's point of view, we gained some industrial perspective. Separately, I have prepared an experience report that is currently seeking a venue. John

1 0

ANN: linearscan, linearscan-hoopl 1.0.0
by John Wiegley 21 Nov '15

21 Nov '15

linearscan[1] is a linear scan register allocator[2], written in Coq[3], and extracted to Haskell, as a library for Haskell programs that need to allocate registers. It may also be used directly from Coq. This project is the result of a year-long effort, funded by BAE Systems[4], to explore the application of dependent-types and mathematical verification to a typical engineering task. During the course of construction, several hundred theorems about the code were proven -- although exhaustive coverage was not, in the end, achievable given our time constraints. To remedy this, and as a test of the extraction to Haskell, an optional runtime verifier was built to certify the resulting allocations. Coq 8.5b2[5] was used, as well as the ssreflect[6] library created for that version[7]. linearscan further relies on another library, coq-haskell[8], that I created to facilitate inter-operation between Haskell and Coq. For those using Hoopl[9] to represent program graphs, incorporating linearscan is quite easy: provide an instance of NodeAlloc using the linearscan-hoopl[10] library. Examples of doing so are provided in the test suite for that library. The allocation algorithm implemented by this library was first written in Java by Hanspeter Mössenböck and Michael Pfeiffer[11], and later improved upon by Christian Wimmer[12], whose master's thesis provided the specification for our implementation. John Wiegley BAE Systems Footnotes: [1] http://hackage.haskell.org/package/linearscan [2] http://www.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf [3] https://coq.inria.fr/ [4] http://www.baesystems.com/en-us/our-company/inc-businesses/electronic-syste… [5] https://coq.inria.fr/news/125.html [6] http://ssr.msr-inria.inria.fr/ [7] http://ssr.msr-inria.inria.fr/FTP/ [8] https://github.com/jwiegley/coq-haskell [9] https://hackage.haskell.org/package/hoopl [10] http://hackage.haskell.org/package/linearscan-hoopl [11] http://dl.acm.org/citation.cfm?id=647478.727924 [12] http://www.christianwimmer.at/Publications/Wimmer04a/

1 0

Expanding the Core Libraries Committee
by Edward Kmett 14 Nov '15

14 Nov '15

At present the core libraries committee consists of 7 members: 6 regular members and one ex-officio appointment for the Haskell Platform maintainer. https://wiki.haskell.org/Core_Libraries_Committee The size of this committee was originally selected to be in line with the size of the extant haskell.org committee. During a meeting of the committee last week, we decided it is a bit too small to fulfill the function of adequately representing the broader community while still providing a sufficient institutional memory. Consequently, we've resolved to replace the current Haskell Platform maintainer appointment with 3 additional seats on the committee. This will grow the committee to 9 members. Pleased be advised, membership on the committee is a commitment to a fairly active role. For more information on some the processes surrounding the core libraries, please see the library submissions page on the Haskell wiki: https://wiki.haskell.org/Library_submissions If you are interested in self-nominating for the core libraries committee, please send an email to core-libraries-committee(a)haskell.org. Thank you for your time and consideration. -Edward Kmett Core Libraries Committee Chair

1 0

Conditionally add OpenBSD's pledge(2) call -- but to which library?
by Matthias Kilian 13 Nov '15

13 Nov '15

Hi, I'd like to add the (OpenBSD only) pledge(2) call to some library in our (OpenBSD's) ghc port. See http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2?query=… and http://www.openbsd.org/papers/hackfest2015-pledge/index.html for some information of what this is about (and Linux people, please don't feel too offended by that second one ;-)) I'd to this as a patch to ghc in our port, but I'd like to eventually submit a patch to include it (conditionally, only on OpenBSD for now) upstream. But I need some hints *where* to include it. At the moment, I'm considering the unix package (bundled with ghc), and therein, the module System.Posix.Unistd. Even if pledge(2) obviously isn't Posix, it's all about stripping down an API which in large parts conforms to Posix to some subset. Would this be acceptable? Or should I use something like System.OpenBSD.Unistd? In any case, client application using it would always either need some #ifdef or would get patches local to the OpenBSD ports tree. So, any thoughts about this? Please note: just writing a separate package for this wouldn't help much (for OpenBSD ports), because it would require changing cabal dependencies for every client application in addition to other source code patches. Ciao, Kili

4 4

Taking a step back
by Johan Tibell 11 Nov '15

11 Nov '15

Friends, I'm taking a step back from day-to-day library work. There are two main reasons I use Haskell: on one hand I find writing Haskell educational and fun. On the other I hope to make it a viable alternative to existing mainstream languages. With recent changes to our core libraries, and the general direction these are moving in, I believe we're moving away from becoming a viable alternative to those mainstream languages. This has some practical implications for how I spend my Haskell hacking time. Much of what I do is maintaining and working on libraries that are needed for real world usage, but that aren't that interesting to work on. I've lost the motivation to work on these. I've decided to take a step back from the core maintenance work on cabal, network, containers, and a few others* starting now. I've already found replacement maintainers for these. I still plan to hack on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :) -- Johan Tibell * For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment with there.

21 28

[cabal] Extract simple static information from PackageDescription
by Jakob Schöttl 08 Nov '15

08 Nov '15

Hello, I have a simple question regarding GenericPackageDescription/ PackageDescription. I don't understand it from the docs: https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-Packag… Google and IRC #haskell also didn't help me. I am trying to extract a simple static information out of the cabal file: the hs-source-dirs Is there a way to get this without resolving conditionals, or with minimal effort? (I don't even understand how to resolving conditionals.) I tried it like this: https://gist.github.com/schoettl/b321baa5002ca48a46c5 But here the PackageDescription has no information (library == Nothing, executables == []). I appreciate any help so much. And I will release the program as an open-source example so that it may help other people in future. Thank you, Jakob -- Jakob Schöttl E-Mail: jschoett(a)gmail.com PGP-Key: 0x25055C7F http://jakob.keramik-schoettl.de

3 5

Proposal: Dot as Postfix Function Apply
by Jeremy 06 Nov '15

06 Nov '15

Dot as Postfix Function Apply (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordField…) was originally part of ORF, but dropped to keep the scope/discussion more manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot postfix syntax. The idea is that instead of (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) we could have person.title ++ " " ++ person.firstName ++ " " ++ person.lastName This is a simple source-to-source translation with no changes to the type system (TDNR is an orthogonal proposal). The advantages are: 1. Code that's easier to read/write. 2. Familiar to users of almost every other programming language. 3. IDE auto-complete - an IDE can suggest functions applicable to the variable after typing . This would be an opt-in extension. I'm posting this to the libraries list because that's where proposals generally go, although this isn't strictly a library issue. If it should be on a different list I'll move it. -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

18 27

3 release policy
by Jeremy 05 Nov '15

05 Nov '15

A "3 release policy" has been recently mentioned several times, whereby it should always be possible to write code that compiles with the last three releases of GHC, without generating any -Wall warnings. The no warning requirement seems excessively harsh. Will early warnings of impending breakage really cause so much trouble that accepted proposals have to be dragged out over several years to avoid them? If so, would a flag to suppress the warnings suffice? I should note that GHC has traditionally had no qualms about introducing new warnings, on by default. -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

17 18

Re: process package with compilers besides GHC
by Malcolm Wallace 03 Nov '15

03 Nov '15

Clean-up is generally good. I have not maintained any Haskell compiler for about 5 years now, so I think it is safe to say you can go ahead. nhc98 did indeed build the 'process' package as part of its library set, but most recently at version 1.0.1.4. Regards, Malcolm On 2 Nov 2015, at 16:21, Michael Snoyman wrote: > Forwarding directly to you, in case you're not reading the mailing lists. > > ---------- Forwarded message ---------- > From: Michael Snoyman <michael(a)snoyman.com> > Date: Mon, Nov 2, 2015 at 8:10 AM > Subject: process package with compilers besides GHC > To: Haskell Cafe <haskell-cafe(a)haskell.org>, libraries <libraries(a)haskell.org> > > > I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: > > 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers > 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC > > I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. > > * No pun intend >

1 0