- Haskell-Cafe - Haskell.org

Munich 13.5., live sequencer
by Heinrich Hördegen 08 May '13

08 May '13

Dear all, Henning Thielemann will give a demonstration of his live sequencer in Munich on the 13th of May (next Monday): http://www.youtube.com/watch?v=88jK162l6mE We begin at 19h00 at Oetingenstr. 67, 80538 Munich, room 157 (first floor, central). As everything is live, please bring your laptops along, if you want to participate interactivly. Heinrich

1 0

Stream fusion and span/break/group/init/tails
by Edward Z. Yang 07 May '13

07 May '13

Hello all, (cc'd stream fusion paper authors) I noticed that the current implementation of stream fusion does not support "multiple-return" stream combinators, e.g. break :: (a -> Bool) -> [a] -> ([a], [a]). I thought a little bit about how might one go about implement this, but the problem seems nontrivial. (One possibility is to extend the definition of Step to support multiple return, but the details are a mess!) Nor, as far as I can tell, does the paper give any treatment of the subject. Has anyone thought about this subject in some detail? Thanks, Edward

8 23

PPDP 2013: 2nd Call for Papers
by Tom Schrijvers 07 May '13

07 May '13

===================================================================== 2nd Call for papers 15th International Symposium on Principles and Practice of Declarative Programming PPDP 2013 Special Issue of Science of Computer Programming (SCP) Madrid, Spain, September 16-18, 2013 (co-located with LOPSTR 2013) http://users.ugent.be/~tschrijv/PPDP2013/ ====================================================================== EXTENDED SUBMISSION DEADLINE: JUNE 13, 2013 PPDP 2013 is a forum that brings together researchers from the declarative programming communities, including those working in the logic, constraint and functional programming paradigms, but also embracing a variety of other paradigms such as visual programming, executable specification languages, database languages, and knowledge representation languages. The goal is to stimulate research in the use of logical formalisms and methods for specifying, performing, and analysing computations, including mechanisms for mobility, modularity, concurrency, object-orientation, security, verification and static analysis. Papers related to the use of declarative paradigms and tools in industry and education are especially solicited. Topics of interest include, but are not limited to: * Functional programming * Logic programming * Answer-set programming * Functional-logic programming * Declarative visual languages * Constraint Handling Rules * Parallel implementation and concurrency * Monads, type classes and dependent type systems * Declarative domain-specific languages * Termination, resource analysis and the verification of declarative programs * Transformation and partial evaluation of declarative languages * Language extensions for security and tabulation * Probabilistic modelling in a declarative language and modelling reactivity * Memory management and the implementation of declarative systems * Practical experiences and industrial application This year the conference will be co-located with the 23nd International Symposium on Logic-Based Program Synthesis and Transformation (LOPSTR 2013) and held in cooperation with ACM SIGPLAN. The conference will be held in Madrid, Spain. Previous symposia were held at Leuven (Belgium), Odense (Denmark), Hagenberg (Austria), Coimbra (Portugal), Valencia (Spain), Wroclaw (Poland), Venice (Italy), Lisboa (Portugal), Verona (Italy), Uppsala (Sweden), Pittsburgh (USA), Florence (Italy), Montreal (Canada), and Paris (France). Papers must describe original work, be written and presented in English, and must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal, conference, or workshop with refereed proceedings. Work that already appeared in unpublished or informally published workshop proceedings may be submitted (please contact the PC chair in case of questions). Proceedings will be published in the ACM International Conference Proceedings Series. After the symposium, a selection of the best papers will be invited to extend their submissions in the light of the feedback solicited at the symposium. The papers are expected to include at least 30% extra material over and above the PPDP version. Then, after another round of reviewing, these revised papers will be published in a special issue of SCP with a target publication date by Elsevier of 2014. Important Dates Abstract Submission: June 10, 2013 Paper submission: June 13, 2013 Notification: July 18, 2013 Camera-ready: August 4, 2013 Symposium: September 16-18, 2013 Invites for SCP: October 2, 2013 Submission of SCP: December 11, 2013 Notification from SCP: February 22, 2014 Camera-ready for SCP: March 14, 2014 Authors should submit an electronic copy of the paper (written in English) in PDF. Each submission must include on its first page the paper title; authors and their affiliations; abstract; and three to four keywords. The keywords will be used to assist us in selecting appropriate reviewers for the paper. Papers should consist of no more than 12 pages, formatted following the ACM SIG proceedings template (option 1). The 12 page limit must include references but excludes well-marked appendices not intended for publication. Referees are not required to read the appendices, and thus papers should be intelligible without them. Program Committee Sergio Antoy Portland State University, USA Manuel Carro IMDEA Software Institute, Spain Iliano Cervesato Carnegie Mellon University, Qatar Agostino Dovier Universita degli Studi di Udine, Italy Maria Garcia de la Banda Monash University, Australia Ralf Hinze University of Oxford, UK Yukiyoshi Kameyama University of Tsukuba, Japan Oleg Kiselyov USA Yanhong Annie Liu State University of New York at Stony Brook, USA Stefan Monnier Universite de Montreal, Canada Alan Mycroft University of Cambrige, UK Bruno C. d. S. Oliveira National University of Singapore, Singapore Alberto Pettorossi Universita di Roma Tor Vergata, Italy Enrico Pontelli New Mexico State University, USA Kristoffer Rose IBM Research, USA Sukyoung Ryu KAIST, South Korea Vitor Santos Costa University of Porto, Portugal Torsten Schaub University Potsdam, Germany Tom Schrijvers Ghent University, Belgium Martin Sulzmann Hochschule Karlsruhe, Germany Wouter Swierstra Universiteit Utrecht, The Netherlands Tarmo Uustalu Institute of Cybernetics, Estonia Janis Voigtlaender University of Bonn, Germany Meng Wang Chalmers University of Technology, Sweden Jan Wielemaker Universiteit van Amsterdam, The Netherlands Program Chair Tom Schrijvers Department of Applied Mathematics and Computer Science Ghent University 9000 Gent, Belgium General Chair Ricardo Pena Facultad de Informatica Universidad Complutense de Madrid 28040 Madrid, Spain

1 0

Request for input on "Programming in Haskell"
by Graham Hutton 07 May '13

07 May '13

Have you taught a course using Hutton's textbook on Programming in Haskell? If so, please read on! As part of the national assessment of universities in the UK that takes place every 5-6 years, I'm producing a case study on the impact of the book on student and professional training. The case study will include a number of quotes from academic and industrial users who have used the book for teaching purposes. If you have taught a course using the book any time from January 2008 onwards, and would be willing to provide a short quote (2-3 sentences) for the case study, that would be very much appreciated. It doesn't matter if you are no longer teaching the course or are not currently using the book. If you are interested, drop me an email and I'll explain what's involved. Many thanks, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell-cafe] Hackage checking maintainership of packages
by Clark Gaebel 07 May '13

07 May '13

If there's a github link in the package url, it could check the last update to the default branch. If it's more than 6 months ago, an email to the maintainer of "is this package maintained?" can be sent. If there's no reply in 3 months, the package is marked as unmaintained. If the email is ever responded to or a new version is uploaded, the package can be un-marked. - Clark On Sunday, May 5, 2013, Lyndon Maydwell wrote: > I've got it! > > The answer was staring us in the face all along... We can just introduce > backwards-compatibility breaking changes into GHC-head and see if the > project fails to compile for x-time! That way we're SURE it's unmaintained. > > I'll stop sending emails now. > > > On Mon, May 6, 2013 at 10:44 AM, Clark Gaebel <cgaebel(a)uwaterloo.ca>wrote: > > If there's a github link in the package url, it could check the last > update to the default branch. If it's more than 6 months ago, an email to > the maintainer of "is this package maintained?" can be sent. If there's no > reply in 3 months, the package is marked as unmaintained. If the email is > ever responded to or a new version is uploaded, the package can be > un-marked. > > - Clark > > > On Sunday, May 5, 2013, Lyndon Maydwell wrote: > > But what if the package is already perfect? > > Jokes aside, I think that activity alone wouldn't be a good indicator. > > > On Mon, May 6, 2013 at 9:59 AM, Conrad Parker <conrad(a)metadecks.org>wrote: > > On 6 May 2013 09:42, Felipe Almeida Lessa <felipe.lessa(a)gmail.com> wrote: > > Just checking the repo wouldn't work. It may still have some activity > > but not be maintained and vice-versa. > > ok, how about this: if the maintainer feels that their repo and > maintenance activities are non-injective they can additionally provide > an http-accessible URL for the maintenance activity. Hackage can then > do an HTTP HEAD request on that URL and use the Last-Modified response > header as an indication of the last time of maintenance activity. I'm > being a bit tongue-in-cheek, but actually this would allow you to > point hackage to a blog as evidence of maintenance activity. > > I like the idea of just pinging the code repo. > > Conrad. > > > On Sun, May 5, 2013 at 2:19 PM, Doug Burke <dburke.gw(a)gmail.com> wrote: > >> > >> On May 5, 2013 7:25 AM, "Petr Pudlák" <petr.mvd(a)gmail.com> wrote: > >>> > >>> Hi, > >>> > >>> on another thread there was a suggestion which perhaps went unnoticed > by > >>> most: > >>> > >>>> ---------- Forwarded message ---------- > >>>> From: Niklas Hambüchen <mail(a)nh2.me> > >>>> Date: 2013/5/4 > >>>> ... > >>>> I would even be happy with newhackage sending every package > maintainer a > >>>> quarterly question "Would you still call your project X 'maintained'?" > >>>> for each package they maintain; Hackage could really give us better > >>>> indications concerning this. > >>> > >>> > >>> This sounds to me like a very good idea. It could be as simple as "If > you > >>> consider yourself to be the maintainer of package X please just hit > reply > >>> and send." If Hackage doesn't get an answer, it'd just would display > some > >>> red text like "This package seems to be unmaintained since D.M.Y." > >>> > >>> Best regards, > >>> Petr > >>> > >> > >> For those packages that give a repository, a query could be done > >> automatically to see when it was last updated. It's not the same thing > as > >> 'being maintained', but is less annoying for those people with many > packages > >> on hackage. > >> > >> Doug > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > > > > > -- > > Felipe. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

6 6

Hackage checking maintainership of packages
by Petr Pudlák 07 May '13

07 May '13

Hi, on another thread there was a suggestion which perhaps went unnoticed by most: ---------- Forwarded message ---------- > From: Niklas Hambüchen <mail(a)nh2.me> > Date: 2013/5/4 > ... > I would even be happy with newhackage sending every package maintainer a > quarterly question "Would you still call your project X 'maintained'?" > for each package they maintain; Hackage could really give us better > indications concerning this. This sounds to me like a very good idea. It could be as simple as "If you consider yourself to be the maintainer of package X please just hit reply and send." If Hackage doesn't get an answer, it'd just would display some red text like "This package seems to be unmaintained since D.M.Y." Best regards, Petr

14 20

Fwd: Backward compatibility
by Adrian May 06 May '13

06 May '13

Oops, forgot hit hit reply-all the first time, well spotted by Niklas... ---------- Forwarded message ---------- From: Adrian May <adrian.alexander.may(a)gmail.com> Date: 5 May 2013 14:22 Subject: Re: [Haskell-cafe] Backward compatibility To: Niklas Hambüchen <mail(a)nh2.me> > The fact that it doesn't build and that the last change is from 2007 the > *is* the warning that it is completely unmaintained and not the way to > do things today. > > (One could even say that by making it build on 7.6, I have removed this > warning and given the illusion that everything is fine.) > That only makes sense if you assume everybody is familiar with Haskell and its culture. But that neglects trying to make it attractive to people who aren't. Of course I agree that it would be better if there were warnings on > their web sites that said "sorry guys, this project is dead now". > > I would even be happy with newhackage sending every package maintainer a > quarterly question "Would you still call your project X 'maintained'?" > for each package they maintain; Hackage could really give us better > indications concerning this. > > Something like that would make a lot of sense to me. > Still I'd say that in this case, the fact that it did not build, hasn't > had a single change in the last half decade, and that you cannot find > any recent discussion about it anywhere on the Internet, make it pretty > clear what is going on here, even for non-technical people. Half a decade is nothing to most programming cultures. A newbie looks for sample code and blames himself if he can't get it working. > > Please don't say that it's my culture's fault. > > From your story it sounds like you have a problem with developer > simplemindedness and management wars idiocy. Nobody is forcing you to be part of that. There are a lot of places ... Perhaps I'd rather help those who need it than preach to the converted. You summed it up nicely as two problems: (1) bitchy managers and (2) untrained programmers. I'd like to use Haskell to help with (2) but I still have to work around (1). My plan is to start by winning the hearts and minds of the developers before sticking my neck out far enough to get it severed. There's another plan where I'm pitching VCs about a start up, in which case I'd have a lot more control, but I'd still have to prove that my elite imperative squad were willing and able to learn a new trick before committing myself. I've actually learned quite a lot from this discussion and that largely enables me to preempt any Rails-day problems. But that's only me. Lots of people might be flirting with Haskell just out of curiosity and bouncing off it for these reasons. There have been a lot of good ideas suggested about how to minimise that, and I'd also throw in that it would be cool if people could tell the compiler to behave as it did half a decade ago when the code was written so people could prove to themselves that the code works in principle, then they could clock the compiler forward little by little, reading its release notes along the way. That's a lot friendlier than being confronted with an apparently endless series of error messages when you've barely learned to read them, and not even knowing if you're making things better or worse. If the desired compiler/modules version was in the makefile, that, I think, would be a general solution. The FPComplete thing also looks helpful. I could use that to sell the language to newbies. The mercenaries would come later though. Thanks to everybody for helping out with this. Adrian.

8 8

help understanding zlib space leak
by diego souza 06 May '13

06 May '13

Dear haskellers, I'd like assistance figuring out a strange space leak using zlib package. To make it easier to reproduce I've come up with the following snippet that pretty much resumes up the problem I'm trying to solve: > -- omitting imports and function signatures > encode = compress . L.fromChunks > > main = do { hSetBinaryMode stdout True > ; hSetBinaryMode stdin True > ; hSetBuffering stdin NoBuffering > ; hSetBuffering stdout NoBuffering > ; loop [] > } > where loop buff > | length buff == 64 = L.hPut stdout (encode buff) >> loop [] > | otherwise = do { eof <- hIsEOF stdin > ; when (not eof) (fmap (: buff) (B.hGetSome stdin 512) >>= loop) > } N.B.: Removing the `compress' function from the above code also removes the space leak. Now, feeding the above program with ~8GB worth of binary data: > $ uname -a Linux mephisto.localhost.localdomain 3.8.7-1-ARCH #1 SMP PREEMPT Sat Apr 13 09:01:47 CEST 2013 x86_64 GNU/Linux > $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 > $ ghc -W -Wall -rtsopts --make -O2 test.hs > $ sudo dd if=/dev/sda bs=4K count=2048K | ./test +RTS -M1M -s >/dev/null ... 8589934592 bytes (8.6 GB) copied, 277.263 s, 31.0 MB/s ... 2 MB total memory in use (0 MB lost due to fragmentation) ... Which is fine. However, monitoring the RSS size is a different story: > $ while pidof test; do ps -o rss= -p $(pidof test); done | tail 16967 25620 16967 25628 16967 25628 16967 25628 16967 # ~16M 0 I know the RSS usually overestimates the memory consumption but the problem is that it is forever growing. The following I found very intriguing: * `+RTS -hc` gives me no hint about whats wrong [at least I couldn't see one]; * `+RTS -M1M` doesn't produce an error; * removing the `compress' functions makes the problem disappear; I couldn't figure these out and I don't think this is matter of strictness, though. Has anyone seen this before? Thanks in advance, ~dsouza

1 1

Follow up on type error diagnosis for DSLs in Haskell
by Jurriaan Hage 05 May '13

05 May '13

Dear all (and in particular Alberto G. Corona and Stephen Tetley), First of all, thanks Stephen for pointing out our work to Alberto. Second, you may be interested to know that I just (as in two weeks ago) obtained a grant to hire a PhD student to scale the work of the ICFP '03 paper (as mentioned by Stephen) up to Haskell 2011 (or whatever variant will be appropriate). The plan is to first prototype this work in the UHC compiler, and, if succesful, build it into the GHC. I shall surely send out a job vancancy on some of the Haskell mailing lists. best, Jurriaan Hage

2 1

[ANN] xmobar 0.17 released
by Jose A. Ortega Ruiz 05 May '13

05 May '13

I've just released version 0.17 of xmobar, a lightweight system monitor written in Haskell. Homepage: http://xmobar.org Release notes: http://xmobar.org/releases.html _New features_ - Icons support: it's now possible to insert bitmaps in the template (Edward O'Callaghan, Alexander Polakov and Tomáš Janoušek). - Initial support for reacting to mouse clicks (Alexander Polakov). - New `TopP` and `BottomP` alignments, taking left and right paddings (thanks to Dmitry Malikov). - New `<freeratio>` field for memory monitor (Peter Simons). - New `allDesktops` and `overrideRedirect` configuration options, providing dock behaviour in tiling WMs (when set to True and False respectively). Cf. discussion at [github #105]. - Experimental `-d` (start as a dock) option, may address [github #67] in some window managers. _Bug fixes_ - Partial (as reports go) fix for [github #77]. - Safer volume plugin (Dmitry Malikov). - Battery percentage capped at 100% (RJ Regenold). Enjoy! -- I always pass on good advice. It's the only thing to do with it. It is never any use to oneself. -Oscar Wilde

1 0