[Haskell-cafe] Haskell Symposium 2012 - Call for Participation (early registration closes 9th August)
CALL FOR PARTICIPATION ACM SIGPLAN Haskell Symposium 2012 Copenhagen, Denmark 13th September, 2012 (directly after ICFP) http://www.haskell.org/haskell-symposium/2012/ The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. The scope of the symposium includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Accepted papers and programme: == * http://haskell.org/haskell-symposium/2012/#schedule REGISTRATION IS NOW OPEN: = * http://www.icfpconference.org/icfp2012/registration.html * Early registration deadline: 9th August, 2012 Local arrangements (including travel and accommodation): * http://www.icfpconference.org/icfp2012/local.html See you in Copenhagen, Janis Voigtlaender Haskell 2012 Programme Chair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] HaL7: Haskell-Treffen in Halle/Saale, Freitag 2012-07-13
I guess we should also give credit to the speakers who contribute the tutorials (which promise to be very interesting): snap: Matthias Fischmann repa: Andres Löh schule: Ralf Dorn reactive: Heinrich Apfelmus generics: Andres Löh liveseq: Johannes Waldmann Best, Janis. Am 06.06.2012 11:54, schrieb Henning Thielemann: For our German readers: Es ist wieder so weit: Am Freitag, 13. Juli laden wir zum 7. Haskell-Treffen HaL ein, diesmal nach Halle an der Saale. Wir bieten eine bunte Mischung aus Tutorien zum Mitmachen, Vortraegen zum Anhoeren und Gelegenheiten zum Fachsimpeln, theoretisches wie praktisches, ernstes wie heiteres. Das Programm im Schnelldurchlauf ist: vormittags 6 Tutorien 09:30 - 11:00 snap repa schule 11:30 - 13:00 reactive generics liveseq nachmittags 4 Vortraege 14:30 - 15:15 Dorn: Schule 15:15 - 16:00 Voigtlaender: ADP 16:30 - 17:15 Goergens: XenClient 17:15 - 18:00 Eijkel: Hommage sonstiges: 09:00 - 11:30 Installationshilfen 11:00 - 11:30 Kaffeepause 13:00 - 14:30 Mittagspause 16:00 - 16:30 Kaffeepause 19:00 - Ende Abendessen und Fachsimpelei im Restaurant Die Details finden Sie hier: http://iba-cg.de/hal7.html und die Anmeldung da: http://sim.mathematik.uni-halle.de:8080/hal7/ Bitte melden Sie sich bis zum 4. Juli an. Wir freuen uns auf Ihr zahlreiches Erscheinen! für das Programmkomitee Henning Thielemann ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tests by properties: origin?
Am 01.06.2012 12:00, schrieb Yves: Out of curiosity, does someone know if QuickCheck was the first test framework working through test by properties associated with random generation or if it drew the idea from something else? Because the idea has be retaken by a lot of frameworks in several languages (seehttp://en.wikipedia.org/wiki/Quickcheck), but I can't find what was QuickCheck inspiration. How about reading the original paper introducing QuickCheck? If the authors drew inspiration from elsewhere, the paper is for sure where they would tell you, first hand. :-) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Am 19.05.2012 12:00, schrieb wren ng thornton: Exactly. That's what I was trying to get at re the problems of comparing Haskell to C++ (or indeed any pair of dissimilar languages). A legitimate comparison will involve far more than microbenchmarks, but then a legitimate comparison must always have a specific focus and context in order to be able to say anything interesting. The problems I see in language comparisons is that by and large they tend not to have any such focus[1], and consequently they shed little light on how the languages compare and shed a bit of darkness by serving only to confirm initial biases. [1] A nice counter-example to this trend are papers like: http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf There was another one comparing the expressivity of Java-style polymorphism vs Haskell-style polymorphism, based on an analysis of in-the-wild code; but I can't seem to pull it up at the moment. Possibly Software extension and integration with type classes by Lämmel and Ostermann? http://doi.acm.org/10.1145/1173706.1173732 Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Symposium 2012 - deadline approaching
will be summarily rejected. Submission is via EasyChair: https://www.easychair.org/conferences/?conf=haskell2012 Programme Committee: * Amal Ahmed, Northeastern University * Jost Berthold, University of Copenhagen * Nils Anders Danielsson, University of Gothenburg * Iavor Diatchki, Galois Inc. * Jeremy Gibbons, University of Oxford * Jurriaan Hage, Utrecht University * Zhenjiang Hu, National Institute of Informatics Tokyo * Daan Leijen, Microsoft Research * Ben Lippmeier, University of New South Wales * Simon Peyton Jones, Microsoft Research * Colin Runciman, University of York * Eijiro Sumii, Tohoku University * Janis Voigtländer (chair), University of Bonn * Brent Yorgey, University of Pennsylvania Links: == * http://www.haskell.org/haskell-symposium (the permanent web page of the Haskell Symposium) * http://www.haskell.org/haskell-symposium/2012 (the 2012 Haskell Symposium web page) * http://www.icfpconference.org/icfp2012 (the ICFP 2012 web page) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Papers - Haskell Symposium 2012 - six weeks to go
Committee: * Amal Ahmed, Northeastern University * Jost Berthold, University of Copenhagen * Nils Anders Danielsson, University of Gothenburg * Iavor Diatchki, Galois Inc. * Jeremy Gibbons, University of Oxford * Jurriaan Hage, Utrecht University * Zhenjiang Hu, National Institute of Informatics Tokyo * Daan Leijen, Microsoft Research * Ben Lippmeier, University of New South Wales * Simon Peyton Jones, Microsoft Research * Colin Runciman, University of York * Eijiro Sumii, Tohoku University * Janis Voigtländer (chair), University of Bonn * Brent Yorgey, University of Pennsylvania Links: == * http://www.haskell.org/haskell-symposium (the permanent web page of the Haskell Symposium) * http://www.haskell.org/haskell-symposium/2012 (the 2012 Haskell Symposium web page) * http://www.icfpconference.org/icfp2012 (the ICFP 2012 web page) -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Transformations and fmap
Ryan Ingram wrote: However, the type of natural transformations comes with a free theorem, for example concat :: [[a]] - [a] has the free theorem forall f :: a - b, f strict and total, fmap f . concat = concat . fmap (fmap f) The strictness condition is needed; consider broken_concat :: [[a]] - [a] broken_concat _ = [undefined] f = const () fmap f (broken_concat []) = fmap f [undefined] = [()] broken_concat (fmap (fmap f) []) = broken_concat [] = [undefined] The 'taming selective strictness' version of the free theorem generator[1] allows removing the totality condition on f, but not the strictness condition. But in the case of concat, you can prove a stronger theorem: forall f :: a - b, fmap f . concat = concat . fmap (fmap f) My suspicion is that this stronger theorem holds for all strict and total natural transformations, but I don't know how to go about proving that suspicion. I'm a hobbyist mathematician and a professional programmer, not the other way around:) ... [1]http://www-ps.iai.uni-bonn.de/cgi-bin/polyseq.cgi There is an analogous approach to the taming selective strictness version of the free theorem generator where it is general recursion that is tamed. In that setting, you then get free theorems like that for concat without either strictness or totality side conditions. It is really very similar, indeed the taming selective strictness work takes over and develops further the much earlier taming general recursion ideas. The original source for the latter is: http://dblp.uni-trier.de/rec/bibtex/conf/esop/LaunchburyP96 Just nobody ever bothered to implement it in a tool. (Well, actually, such an implementation is essentially hidden inside the counterexample generator http://www-ps.iai.uni-bonn.de/cgi-bin/exfind.cgi) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Papers - Haskell Symposium 2012
of Gothenburg * Iavor Diatchki, Galois Inc. * Jeremy Gibbons, University of Oxford * Jurriaan Hage, Utrecht University * Zhenjiang Hu, National Institute of Informatics Tokyo * Daan Leijen, Microsoft Research * Ben Lippmeier, University of New South Wales * Simon Peyton Jones, Microsoft Research * Colin Runciman, University of York * Eijiro Sumii, Tohoku University * Janis Voigtländer (chair), University of Bonn * Brent Yorgey, University of Pennsylvania Links: == * http://www.haskell.org/haskell-symposium (the permanent web page of the Haskell Symposium) * http://www.haskell.org/haskell-symposium/2012 (the 2012 Haskell Symposium web page) * http://www.icfpconference.org/icfp2012 (the ICFP 2012 web page) -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell at University in Munich
Am 05.12.2011 12:00, schrieb bar...@sudety.it: Hello Haskell Cafe, I would be grateful for any information regarding Haskell (or at least Functional Programming) lectures at Universities near to Munich, Germany (Master or Bachelor). Unconfirmed information I've got regarding LMU and TUM are not promising. Is Munich really that bad? FP'ers at LMU and TUM, please speak up. (I know that at least research-wise there are quite a few around there, though I don't know what they do in teaching.) If Munich and 200 km circle do not provide with any offer, perhaps Less than 200 km from Munich: http://db.inf.uni-tuebingen.de/teaching/ws1112/afp Also, Germany extends farther than 200 km beyond Munich. :-) Say, Bonn: http://www.iai.uni-bonn.de/~jv/teaching/dp11/ http://www.iai.uni-bonn.de/~jv/teaching/ffp/ you may know what is available in Europe, limiting language of study to [German, English,Polish]? The thread Sean pointed to may provide information on that. Obvious candidates are Utrecht and Chalmers, both teaching in English I suppose, at least at Master level. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (21st ed., November 2011)
On behalf of all the contributors, I am pleased to announce that the Haskell Communities and Activities Report (21st edition, November 2011) is now available in PDF and HTML formats: http://haskell.org/communities/11-2011/report.pdf http://haskell.org/communities/11-2011/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: = End of April 2012: target deadline for contributions to the May 2012 edition of the HCA Report = Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in April (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The best way to call Java from Haskell?
Ketil Malde ke...@malde.org writes: Jerzy Karczmarczukjerzy.karczmarc...@unicaen.fr writes: Don't worry, my friend. Haskell is lazy, so there is no problem in handling those infinite modules. It will just take you an infinite amount of time before you get any money from such a work. But this is a general problem elsewhere as well. I guess you must be thinking of Haskell being increasingly used in banks? It must have been some bank manager who, after hiring one too many Haskell programmers, invented a scheme that would generate an infinite amount of money. He didn't realize before it was too late that the actual value of the scheme would be bottom... See also: http://www.haskell.org/haskellwiki/Humor/Enron -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, November 2011 edition
Dear all, I would like to collect contributions for the 21st edition of the Haskell Communities Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 1 November 2011 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the May 2011 edition --- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Janis (current editor) FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/11-2011/template.tex There is also a LaTeX style file at http://haskell.org/communities/11-2011/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should already have received your old entry as a template (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please consider using lhs2tex syntax (http://people.cs.uu.nl/andres/lhs2tex/). The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. If you have several entries to submit, it helps if you send them in separate emails. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. This corresponds to approximately one page, or 40 lines of text, with the above style and template. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or historic overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write wishlist items for libraries and language features you would like to see implemented. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is
Re: [Haskell-cafe] [Haskell] ANN: boomerang and web-routes-boomerang
Am 21.07.2011 20:45, schrieb Jeremy Shaw: Hello, I am pleased to announce the release of two new libraries: boomerang and web-routes-boomerang. Does this have anything to do with: Boomerang: A bidirectional programming language for ad-hoc data http://www.seas.upenn.edu/~harmony/ ? If not, is it wise to name it thus? Wondering, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANN: boomerang and web-routes-boomerang
Am 21.07.2011 21:19, schrieb Jeremy Shaw: Nope. It is not related. It is also not related to the GSM library: http://www.programmersheaven.com/download/29760/download.aspx or the decompiler: http://boomerang.sourceforge.net/index.php Perhaps picking an original name would have been a wise choice. But it was the only I idea I had :) I am only inclined to change it if there is a strong chance of people wanting to use the boomerang name on hackage to refer to something related to the harmony boomerang project.. Well, I don't know. But as a matter of fact, the Boomerang language is much closer to your library in spirit (and possibly techniques) than any of the other projects you mention. First hit at Google for Boomerang functional programming - http://www.seas.upenn.edu/~harmony/ Also, it does have parsers and pretty printers as one application instance. So there is potential for confusion. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (20th ed., May 2011)
On behalf of all the contributors, I am pleased to announce that the Haskell Communities and Activities Report (20th edition, May 2011) is now available in PDF and HTML formats: http://haskell.org/communities/05-2011/report.pdf http://haskell.org/communities/05-2011/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: == End of October 2011: target deadline for contributions to the November 2011 edition of the HCA Report == Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in October (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] REMINDER: Haskell Communities and Activities Report, May 2011 edition
Dear all, It is not yet too late to contribute to the 20th edition of the Haskell Communities Activities Report http://tinyurl.com/haskcar Submission deadline: this weekend (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) If you haven't already, please write an entry for your new project or update your old entry. More information can be found in the original Call for Contributions at http://www.haskell.org/pipermail/haskell/2011-April/022720.html I look forward to your contributions, Janis (current editor) -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Questioning seq
Am 14.04.2011 18:57:35 schrieb Andrew Coppinandrewcop...@btinternet.com: A couple of questions: 1. Why is the existence of polymorphic seq bad? See http://www.iai.uni-bonn.de/~jv/acta.pdf, Sections 1 and 2 and pointers therein. Also, numerous discussions on this list over the years. Best, Janis. 2. Why would the existence of polymorphic rnf be worse? 3. How is pseq different from seq? That is all... -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2011 edition
Dear all, I would like to collect contributions for the 20th edition of the Haskell Communities Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 1 May 2011 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the November 2010 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Janis (current editor) FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2011/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2011/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should already have received your old entry as a template (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please consider using lhs2tex syntax (http://people.cs.uu.nl/andres/lhs2tex/). The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. If you have several entries to submit, it helps if you send them in separate emails. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. This corresponds to approximately one page, or 40 lines of text, with the above style and template. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or historic overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write wishlist items for libraries and language features you would like to see implemented. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is
Re: [Haskell-cafe] Byte Histogram
On 2/5/11 4:26 AM, Claus Reinke wrote: Lately I've been trying to go the other direction: make a large section of formerly strict code lazy. There used to be a couple of tools trying to make suggestions when a function could be made less strict (Olaf Chitil's StrictCheck and another that escapes memory at the moment). Probably Sloth: http://korsika.informatik.uni-kiel.de/~jac/wordpress/ http://korsika.informatik.uni-kiel.de/~jac/wordpress/wp-content/uploads/PADL2011.pdf Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (19th ed., November 2010)
On behalf of all the contributors, I am pleased to announce that the Haskell Communities and Activities Report (19th edition, November 2010) is now available in PDF and HTML formats: http://haskell.org/communities/11-2010/report.pdf http://haskell.org/communities/11-2010/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: End of April 2011: target deadline for contributions to the May 2011 edition of the HCA Report Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in April (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, November 2010 edition
Dear all, It is time to collect contributions for the 19th edition of the Haskell Communities Activities Report http://www.haskell.org/communities/ Submission deadline: 1 November 2010 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the May 2010 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Janis (current editor) FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/11-2010/template.tex There is also a LaTeX style file at http://haskell.org/communities/11-2010/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should already have received your old entry as a template (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. If you have several entries to submit, it helps if you send them in separate emails. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. This corresponds to approximately one page, or 40 lines of text, with the above style and template. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or historic overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write wishlist items for libraries and language features you would like to see implemented. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them.
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: Actually I think we can keep the old generic seq, but cutting its full polymorphism: seq :: Typeable a = a - b - b I guess I don't know enough about Typeable to appreciate that. Basically the Typeable constraints tells that we dynamically know the identity of the type being passed in. So this may be a bit challenging to cleanly explain how this safely disable the parametricity but in the mean time this is the net result the type is dynamically known at run time. ... However I would like to here more comments about this seq variant, anyone? On reflection, isn't Typeable actually much too strong a constraint? Given that it provides runtime type inspection, probably one cannot derive any parametricity results at all for a type variable constrained by Typeable. In contrast, for a type variable constrained via a hypothetical (and tailored to seq) Eval-constraint, one still gets something which looks like a standard free theorem, just with some side conditions relating to _|_ (strictness, totality, ...). In other words, by saying seq :: Typeable a = a - b - b, you assume pessimistically that seq can do everything that is possible on members of the Typeable class. But that might be overly pessimistic, since in reality the only thing that seq can do is evaluate an arbitrary expression to weak head normal form. OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, Oh, YES. That's the point of a free theorem, isn't it: that I only need to look at the type of the function to derive some property about it. I want them to always apply when no call to unsafe function is made. Well, the question is what you mean by no call to unsafe function is made. Where? In the function under consideration, from whose type the free theorem is derived? Are you sure that this is enough? Maybe that function f does not contain a call to unsafeSeq, but it has an argument which is itself a function. Maybe in some function application, unsafeSeq is passed to f in that argument position, directly or indirectly. Maybe f does internally apply that function argument to something. Can you be sure that this will not lead to a failure of the free theorem you derived from f's type (counting on the fact that f does not call an unsafe function)? Of course, preventing the *whole program* from calling unsafeSeq is enough to guarantee validity of the free theorems thus derived. But that's equivalent to excluding seq from Haskell altogether. It depends on the unsafe function that is used. Using unsafeCoerce or unsafePerformIO (from which we can derive unsafeCoerce) badely anywhere suffice to break anything. So while seq is less invasive I find it too much invasive in its raw form. Hmm, from this answer I still do not see what you meant when you said you want free theorems to always apply when no call to seq is made. You say that seq is less invasive, so do you indeed assume that as soon as you are sure a function f does not itself (syntactically) contain a call to seq you are safe to use the standard free theorem derived from f's type unconstrained? Do you have any justification for that? Otherwise, we are back to banning seq completely from the whole program/language, in which case it is trivial that no seq-related side conditions will be relevant. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. I would consider it as a safe function. Well, then I fear you have come full-circle back to a non-solution. It is not safe: Consider the example foldl''' from our paper, and replace seq therein by your genericSeq. Then the function will have the same type as the original foldl, but the standard free theorem for foldl does not hold for foldl''' (as also shown in the paper). Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. I would consider it as a safe function. Well, then I fear you have come full-circle back to a non-solution. It is not safe: I feared a bit... but no Consider the example foldl''' from our paper, and replace seq therein by your genericSeq. Then the function will have the same type as the original foldl, but the standard free theorem for foldl does not hold for foldl''' (as also shown in the paper). So foldl''' now has some Typeable constraints. No, I don't see how it has that. Or maybe you should make explicit under what conditions a type (a - b) is in Typeable. What exactly will the type of foldl''' be, and why? Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: Right let's make it more explicit, I actually just wrote a Control.Seq module and a test file: module Control.Seq where genericSeq :: Typeable a = a - b - b genericSeq = Prelude.seq class Seq a where seq :: a - b - b instance (Typeable a, Typeable b) = Seq (a - b) where seq = genericSeq ... Other seq instances ... $ cat test.hs import Prelude hiding (seq) import Data.Function (fix) import Control.Seq (Seq(seq)) import Data.Typeable ... foldl''' :: (Typeable a, Typeable b) = (a - b - a) - a - [b] - a -- GHC infer this one -- foldl''' :: Seq (a - b - a) = (a - b - a) - a - [b] - a -- however this one require FlexibleContext, and the first one is accepted. foldl''' c = seq c (fix (\h n ys - case ys of [] - n x : xs - let n' = c n x in h n' xs)) Well, in this example you were lucky that the function type on which you use seq involves some type variables. But consider this example: f :: (Int - Int) - a - a f h x = seq h x I think with your definitions that function will really have that type, without any type class constraints on anything. So let us derive the free theorem for that type. It is: forall t1,t2 in TYPES, g :: t1 - t2, g strict. forall p :: Int - Int. forall q :: Int - Int. (forall x :: Int. p x = q x) == (forall y :: t1. g (f p y) = f q (g y)) Now, set p :: Int - Int p = undefined q :: Int - Int q _ = undefined Clearly, forall x :: Int. p x = q x holds. So it should be the case that for every strict function g and type-appropriate input y it holds: g (f p y) = f q (g y) But clearly the left-hand side is undefined (due to strictness of g and f p y = f undefined y = seq undefined y), while the right-hand side is not necessarily so (due to f q (g y) = f (\_ - undefined) (g y) = seq (\_ - undefined) (g y) = g y). So you have claimed that by using seq via genericSeq in the above definition of f you are guaranteed that any free theorem you derive from its type is correct. But as you see above it is not! I think you have to face it: if you want a solution that both gives meaningful free theorems and still allows to write all programs involving seq that you can currently write in Haskell, then using type classes is not the answer. Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (kein Betreff)
Stefan Holdermans wrote: The point of this discussion is that the Eval constraint needs to be on one of the functions. So I tried to specify that (x - Int) and (y - Int) are different types despite x and y being the same type, because one of them has an Eval constraint. This may be a shortcoming of Haskell (or System Fc?) types, although it may be doable with a newtype. That was kind of what my thinking out loud was getting at. If you want x - Int and y - Int to be different types even if x and y actually are the same type, then apparently you want x - Int and y - Int to be built from different function-space constructors, say - and -*, yielding x - Int and y -* Int. Replacing equals for equals again, you get x - Int and x -* Int. So, basically, we are annotating function types, what is IIRC exactly what Janis and David are doing. (I hope Janis corrects me if I'm wrong here). Wrong only in that David's name is Daniel. :-) Other than that, I agree. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: - If there is no class instance for function types, then those problems go away, of course. But it is doubtful whether that would be a viable solution. Quite a few programs would be rejected as a consequence. (Say, you want to use the strict version of foldl. That will lead to a type class constraint on one of the type variables. Now suppose you actually want to fold in a higher-order fashion, like when expressing efficient reverse via foldr. That would not anymore be possible for the strict version of foldl, as it would require the type-class-constrained variable to be instantiated with a function type.) I think it would be a step forward. The old seq would still exists as unsafeSeq and such applications could continue to use it. In the mean time parametricity results would better apply to programs without unsafe functions. And this without adding extra complexity into the type system. Yes, I agree. Of course, you (and Lennart, and others advocating putting seq into a type class) could work toward that solution right away, could have done so for quite some time: write a package with an Eval type class and method safeSeq (and *no* class instance for function types), upload it on Hackage, encourage people to use it. Modulo the naming difference seq/safeSeq vs. unsafeSeq/seq, that's exactly the solution you want. I wonder why it is not happening. :-) Actually I think we can keep the old generic seq, but cutting its full polymorphism: seq :: Typeable a = a - b - b I guess I don't know enough about Typeable to appreciate that. OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, Oh, YES. That's the point of a free theorem, isn't it: that I only need to look at the type of the function to derive some property about it. I want them to always apply when no call to unsafe function is made. Well, the question is what you mean by no call to unsafe function is made. Where? In the function under consideration, from whose type the free theorem is derived? Are you sure that this is enough? Maybe that function f does not contain a call to unsafeSeq, but it has an argument which is itself a function. Maybe in some function application, unsafeSeq is passed to f in that argument position, directly or indirectly. Maybe f does internally apply that function argument to something. Can you be sure that this will not lead to a failure of the free theorem you derived from f's type (counting on the fact that f does not call an unsafe function)? Of course, preventing the *whole program* from calling unsafeSeq is enough to guarantee validity of the free theorems thus derived. But that's equivalent to excluding seq from Haskell altogether. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Hi again, Maybe I should add that, maybe disappointingly, I do not even have a strong opinion about whether seq should be in Haskell or not, and in what form. Let me quote the last paragraph of an extended version of our paper referred to earlier: Finally, a natural question is whether or not selective strictness should be put under control via the type system in a future version of Haskell (or even removed completely). We have deliberately not taken a stand on this here. What was important to us is that both the costs and benefits of either way should be well understood when making such a decision. Maybe the realization that, contrary to popular opinion, a relatively simple approach like the one that was present in Haskell version 1.3 does not suffice to keep selective strictness in check, and that instead something slightly less wieldy, like our type system presented here or a similar one, would be needed, will quell the recurring calls for putting seq in a type class once and for all. Even then, while it would mean that our type system does not get adopted in practice, we would consider our effort well invested. At least, the community would then have made an informed decision, and part of the justification would be on record. That's under the assumption that the requirements we have on a solution are: 1. All Haskell programs that could be written before should still be implementable, though potentially with a different type. 2. Parametricity results derived from the (new) types should hold, even if seq is involved. The Haskell 1.3 approach achieves 1. but not 2. The approach of an Eval class without a function type instance achieves 2. but not 1. Lennart suggested that the programs one loses that (latter) way might be few in practice. I have no idea whether that is true, but it might well be. But it is actually new to me that proponents of putting seq in a type class admit that they can only do so and achieve 2. by accepting to give up 1. In the past, also in the Being lazy with class paper, the impression was given that the controversial issue about the Haskell 1.3 solution were just its practicality in terms of how cumbersome or not the additional typing artifacts become. While it was simply supposed that at least that solution achieves both 1. and 2. It does not. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Laziness question
Hi, I am late to reply in this thread, but as I see Stefan has already made what (also from my view) are the main points: - Putting seq in a type class makes type signatures more verbose, which one may consider okay or not. In the past (and, as it seems, again in every iteration of the language development process since then) the majority of the language design decision makers have considered this verbosity non-okay enough, so that they decided to have a fully polymorhpic seq. - Even if putting seq in a type class, problems with parametricity do not simply vanish. The question is what instances there will be for that class. (For example, if there is not instance at all, then no seq-related problems of *any* nature can exist...) - The Haskell 1.3 solution was to, among others, have a class instance for functions. As we show in the paper Stefan mentioned, that is not a solution. Some statements claimed by parametricity will then still be wrong due to seq. - If there is no class instance for function types, then those problems go away, of course. But it is doubtful whether that would be a viable solution. Quite a few programs would be rejected as a consequence. (Say, you want to use the strict version of foldl. That will lead to a type class constraint on one of the type variables. Now suppose you actually want to fold in a higher-order fashion, like when expressing efficient reverse via foldr. That would not anymore be possible for the strict version of foldl, as it would require the type-class-constrained variable to be instantiated with a function type.) Two more specific answers to Nicolas' comments: Actually my point is that if we do not use any polymorphic primitive to implement a family of seq functions then it cannot be flawed. Indeed if you read type classes as a way to implicitly pass and pick functions then it cannot add troubles. Completely correct. But the point is that without using any polymorphic primitive you won't be able to implement a member of that family for the case of function types (which you do not consider a big restriction, but others do). However I absolutely do not buy their argument using as example a function f :: Eval (a - Int) = (a - Int) - (a - Int) - Int. They consider as an issue the fact that the type does not tell us on which argument seq is used. I think it is fine we may want a more precise type for it to get more properties out of it but it is not flawed. As much as we don't know where (==) is used given a function of type ∀ a. Eq a = [a] - [a]. I fear you do not buy our argument since you did not fully understand what our argument is, which in all probability is our fault in not explaining it enough. The point is not that we dislike per se that one doesn't know from the type signature how/where exactly methods from a type class are used. In your example ∀ a. Eq a = [a] - [a] it's alright that we don't know more about where (==) is used. But for a function of type f :: Eval (a - Int) = (a - Int) - (a - Int) - Int, in connection with trying to find out whether uses of seq are harmful or not, it is absolutely *essential* to know on which of the two functions (a - Int) seq is used. The type class approach cannot tell that. Hence, a type class approach is unsuitable for trying to prevent seq from doing parametricity-damage while still allowing to write all the Haskell programs one could before (including ones that use seq on functions). That is the flaw of the type class approach to controlling seq. It is of course no flaw of using type classes in Haskell for other things, and we certainly did not meant to imply such a thing. Best regards, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (18th ed., May 2010)
On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (18th edition, May 2010) is now available in PDF and HTML formats: http://haskell.org/communities/05-2010/report.pdf http://haskell.org/communities/05-2010/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: End of October 2010: target deadline for contributions to the November 2010 edition of the HCA Report Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in October (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] REMINDER: Haskell Communities and Activities Report
Dear all, It is not yet too late to contribute to the 18th edition of HCAR. If you haven't already, please write an entry for your new project or update your old entry, and send to me this weekend or early next week. More information about format etc. can be found in the original call: http://www.haskell.org/pipermail/haskell/2010-April/022012.html I am looking forward to receiving your contributions, Janis (current editor) -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2010 edition
Dear all, I would like to collect contributions for the 18th edition of the Haskell Communities Activities Report http://www.haskell.org/communities/ Submission deadline: 1 May 2010 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the November 2009 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Janis (current editor) FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2010/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2010/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should already have received your old entry as a template (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. This corresponds to approximately one page, or 40 lines of text, with the above style and template. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or historic overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write wishlist items for libraries and language features you would like to see implemented. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: searching a function by providing examples of input/ouput pairs
Paul Brauner schrieb: Hi, I was looking at hoogle documentation when I remembered that there is some nice, but quite unusable, feature of squeak (smalltalk) which allows you to search function in the library by giving a list of pairs of inputs/ouputs. When I'm saying that it is quite unusable, I mean that squeak has to try _every_ function, some of which may be very slow to deliver a result, or require some side effects. But, piggibacking such a feature on top of hoogle would surely be more efficient: 1. infer types for arguments and outout 2. look for matching functions using google 3. test them Has anyone tried that before? If not I would be glad to. Sounds like something useful to have. And you could even have the system use a list of pairs of inputs/outputs to give you functions that are *not* yet in any library. :-) http://www.haskell.org/communities/11-2009/html/report.html#sect6.11.1 -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Free theorem - what do we need it for
Maciej Piechotka wrote: I am afraid that I fail to see practical benefits (I mean that I don't know all implication not that I think there is no benefits). What are the benefits of free theorem except large chance that data will Lots of applications. See page 34 (along with the references starting from page 218) of http://www.iai.uni-bonn.de/~jv/ppl2010-slides.pdf for a list of some of them. Ciao, Janis -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Codensity improvement of free monads
On Mon, Jan 25, 2010 at 7:37 PM, Luke Palmer lrpal...@gmail.com wrote: Hello haskell-cafe, I have just read Asymptotic Improvement of Computations over Free Monads by Janis Voigtlander, since I have been working with free monads a lot recently and don't want to get hit by their quadratic performance when I start to care about that. But after reading the paper, I still don't really understand how improve actually improves anything. Can anyone provide a good explanation for where the work is saved? Edward gives the perfect explanation below. Thanks, Janis. With a free monad, the structure keeps growing via substitution. This requires you on each bind to re-traverse the common root of the free monad, which isn't changing in each successive version. Lets say the size of this accumulated detritus increases by one each time. Then you will be traversing over 1, 2, 3, 4, ... items to get to the values that you are substituting as you keep binding your free monadic computation. The area near the root of your structure keeps getting walked over and over, but there isn't any work do to there, the only thing bind can do is substitution, and all the substitution is down by the leaves. On the other hand, when you have CPS transformed it, at each layer you only have to climb over the 1 item you just added to get to where you apply the next computation. This only gets better when you are dealing with free monads that provide multiple points for extension: i.e. that grow in a treelike fashion like: data Bin a = Bin a a data Free f a = Return a | Free (f (Free f a)) data Codensity f a = Codensity (forall r. (a - f r) - f r) If you build the free monad Free Bin, then you will wind up having to walk all the way down to the leaves on each bind, well, modulo demand, that is. But since it is a free monad, the 'body' of the tree will never change. Just the data you are substituting at the leaves. Codensity (Free Bin) lets you only generate the body of the tree once, while your substitutions just get pushed down to the leaves in one pass. An interesting exercise is to work out why Codensity can change the asymptotics of certain operations over Free Bin, but Density doesn't change the asymptotics of anything non-trivial over Cofree Bin for the better. -Edward Kmett -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Presentation about ICFP'09 programming contest
Hi Haskell folk, If you are in Madrid tomorrow (Monday), you will likely not want to miss the video presentation by Andy Gill and his group about the techniques behind their running the ICFP'09 programming contest: http://www.program-transformation.org/PEPM10/SpecialFeature The presentation is scheduled to start 17:15, in the PEPM workshop room. Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Fwd: Termination Competition 2009 live on the web!]
Hi all, This contest should be of interest to Haskellers. There is an FP Category in which termination of Haskell programs is automatically checked. The current state can be observed by following the corresponding View Results link from the page http://termcomp.uibk.ac.at/termcomp/competition/categoryList.seam?competitionId=101722cid=51 Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ---BeginMessage--- Termination Competition 2009 December 16-20 The annual termination competition has started today. The progress of the competition can be seen live on the web at http://termcomp.uibk.ac.at/termcomp/competition/categoryList.seam?competitionId=101722cid=51 As usual, the most powerful termination provers compete against each other in this competition. The competition has several categories for termination analysis of different programming paradigms, including * Term Rewriting * Java Bytecode * Haskell * Prolog * etc. Moreover, there are competitions on * certified termination analysis and on * automated complexity analysis. More information can be found at http://termcomp.uibk.ac.at/status/rules.html ---End Message--- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why?
Andrew Coppin wrote: On the other hand, turn up the optimisation settings on a C compiler high enough and the program breaks. Somewhere the compiler elides a second call to a function which actually happens to have some side-effect that the compiler isn't aware of, and your stream is now one byte out of alignment, or whatever. Fiddling with optimisation settings in GHC may make your program slow to a crawl rather than go faster, but it *never* makes it segfault on startup. Note, though, that slow to crawl may go as far as not terminate. GHC's optimizer can make a terminating program nonterminating. For some discussion, see: http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#Discussion In fact, one can also make up examples where turning on optimization lets GHC transform a good program into one halting with an arbitrary error (division by zero, say). The recipe for (artificial) such examples can be found in footnote 2 of: http://www.iai.uni-bonn.de/~jv/TUD-FI09-06.pdf The error in the wild that is mentioned on the wiki page occurred in the context of the stream fusion library development. Best regards, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lots of Haskell at PEPM 2010 - Call for Participation
Hi all, If you are planning to go to Madrid in January, for POPL, don't forget registering for PEPM as well! If you haven't yet been planning to go, maybe you want to reconsider, for PEPM if not for POPL. Why, you ask? Well, the PEPM program has *lots* of Haskell this year. Indeed, no fewer than 10 of the 21 presentations are directly related to Haskell. And the other papers are great, too, and many of them will be interesting to Haskell folk as well. Scan the speakers and titles below, and you will know why I think you won't want to miss out on that one. Best regards, Janis. === CALL FOR PARTICIPATION ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 === Abstracts of all papers and presentations are available from the above web site. INVITED TALKS: * Lennart Augustsson (Standard Chartered Bank, UK) Title: O, Partial Evaluator, Where Art Thou? * Jeremy Siek (University of Colorado at Boulder, USA) Title: General Purpose Languages Should be Metalanguages. CONTRIBUTED TALKS: * Nabil el Boustani and Jurriaan Hage. Corrective Hints for Type Incorrect Generic Java Programs. * Johannes Rudolph and Peter Thiemann. Mnemonics: Type-safe Bytecode Generation at Run Time. * Elvira Albert, Miguel Gomez-Zamalloa and German Puebla. PET: A Partial Evaluation-based Test Case Generation Tool for Java Bytecode. * Martin Hofmann. Igor2 - an Analytical Inductive Functional Programming System. * José Pedro Magalhães, Stefan Holdermans, Johan Jeuring and Andres Löh. Optimizing Generics Is Easy! * Michele Baggi, María Alpuente, Demis Ballis and Moreno Falaschi. A Fold/Unfold Transformation Framework for Rewrite Theories extended to CCT. * Hugh Anderson and Siau-Cheng KHOO. Regular Approximation and Bounded Domains for Size-Change Termination. * Évelyne Contejean, Pierre Courtieu, Julien Forest, Andrei Paskevich, Olivier Pons and Xavier Urbain. A3PAT, an Approach for Certified Automated Termination Proofs. * Fritz Henglein. Optimizing Relational Algebra Operations Using Generic Equivalence Discriminators and Lazy Products. * Adrian Riesco and Juan Rodriguez-Hortala. Programming with Singular and Plural Non-deterministic Functions. * Martin Hofmann and Emanuel Kitzelmann. I/O Guided Detection of List Catamorphisms. * Andrew Moss and Dan Page. Bridging the Gap Between Symbolic and Efficient AES Implementations. * Christopher Brown and Simon Thompson. Clone Detection and Elimination for Haskell. * Stefan Holdermans and Jurriaan Hage. Making Stricterness More Relevant. * Arun Lakhotia, Davidson Boccardo, Anshuman Singh and Aleardo Manacero Júnior. Context-Sensitive Analysis of Obfuscated x86 Executables. * Xin Li and Mizuhito Ogawa. Conditional Weighted Pushdown Systems and Applications. * Ivan Lazar Miljenovic. The SourceGraph Program. * Florian Haftmann. From Higher-Order Logic to Haskell: There and Back Again. SPECIAL FEATURE: * Andy Gill, Garrin Kimmell and Kevin Matlage. Capturing Functions and Catching Satellites. IMPORTANT DATES: * Early registration deadline: December 22, 2009 * Hotel registration deadline: December 28, 2009 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (17th ed., November 2009)
On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (17th edition, November 2009) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in PDF and HTML formats. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: End of April 2010: target deadline for contributions to the May 2010 edition of the HCA Report Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in October (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Participation - PEPM'10 (co-located with POPL'10)
=== CALL FOR PARTICIPATION ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 === Abstracts of all papers and presentations are available from the above web site. INVITED TALKS: * Lennart Augustsson (Standard Chartered Bank, UK) Title: O, Partial Evaluator, Where Art Thou? * Jeremy Siek (University of Colorado at Boulder, USA) Title: General Purpose Languages Should be Metalanguages. SPECIAL FEATURE: * Andy Gill, Garrin Kimmell and Kevin Matlage. Capturing Functions and Catching Satellites. CONTRIBUTED TALKS: * Nabil el Boustani and Jurriaan Hage. Corrective Hints for Type Incorrect Generic Java Programs. * Johannes Rudolph and Peter Thiemann. Mnemonics: Type-safe Bytecode Generation at Run Time. * Elvira Albert, Miguel Gomez-Zamalloa and German Puebla. PET: A Partial Evaluation-based Test Case Generation Tool for Java Bytecode. * Martin Hofmann. Igor2 - an Analytical Inductive Functional Programming System. * José Pedro Magalhães, Stefan Holdermans, Johan Jeuring and Andres Löh. Optimizing Generics Is Easy! * Michele Baggi, María Alpuente, Demis Ballis and Moreno Falaschi. A Fold/Unfold Transformation Framework for Rewrite Theories extended to CCT. * Hugh Anderson and Siau-Cheng KHOO. Regular Approximation and Bounded Domains for Size-Change Termination. * Évelyne Contejean, Pierre Courtieu, Julien Forest, Andrei Paskevich, Olivier Pons and Xavier Urbain. A3PAT, an Approach for Certified Automated Termination Proofs. * Fritz Henglein. Optimizing Relational Algebra Operations Using Generic Equivalence Discriminators and Lazy Products. * Adrian Riesco and Juan Rodriguez-Hortala. Programming with Singular and Plural Non-deterministic Functions. * Martin Hofmann and Emanuel Kitzelmann. I/O Guided Detection of List Catamorphisms. * Andrew Moss and Dan Page. Bridging the Gap Between Symbolic and Efficient AES Implementations. * Christopher Brown and Simon Thompson. Clone Detection and Elimination for Haskell. * Stefan Holdermans and Jurriaan Hage. Making Stricterness More Relevant. * Arun Lakhotia, Davidson Boccardo, Anshuman Singh and Aleardo Manacero Júnior. Context-Sensitive Analysis of Obfuscated x86 Executables. * Xin Li and Mizuhito Ogawa. Conditional Weighted Pushdown Systems and Applications. * Ivan Lazar Miljenovic. The SourceGraph Program. * Florian Haftmann. From Higher-Order Logic to Haskell: There and Back Again. IMPORTANT DATES: * Early registration deadline: December 22, 2009 * Hotel registration deadline: December 28, 2009 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
