- Haskell-Cafe - Haskell.org

[TFPIE 2015] 2nd call for papers
by Peter Achten 05 Mar '15

05 Mar '15

Trends in Functional Programming in Education (TFPIE 2015) 2nd Call for papers https://wiki.science.ru.nl/tfpie/TFPIE2015 The 4th International Workshop on Trends in Functional Programming in Education, TFPIE 2015, will be held on June 2, 2015 in Sophia-Antipolis in France. It is co-located with the Symposium on Trends in Functional Programming (TFP 2015) which takes place from June 3 - 5. *** Goal *** The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chair of TFPIE 2015 will screen submissions to ensure that all presentations are within scope and are of interest to participants. Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website/wiki. Visitors to the TFPIE 2015 website/wiki will be able to add comments. This includes presenters who may respond to comments and questions as well as provide pointers to improvements and follow-up work. After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. TFPIE workshops have previously been held in St Andrews, Scotland (2012), Provo Utah, USA (2013), and Soesterberg, The Netherlands (2014). *** Program Committee *** Peter Achten, Radboud University Nijmegen, The Netherlands Edwin Brady, University of St Andrews, UK Johan Jeuring, Utrecht University and Open University, The Netherlands (Chair) Shriram Krishnamurthi, Brown University, US Rita Loogen, Philipps-Universität Marburg, Germany Marco Morazan, Seton Hall University, US Norman Ramsey, Tufts University, US *** Submission Guidelines *** TFPIE 2015 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: - FP and beginning CS students - FP and Computational Thinking - FP and Artificial Intelligence - FP in Robotics - FP and Music - Advanced FP for undergraduates - Tools supporting learning FP - FP in graduate education - Engaging students in research using FP - FP in Programming Languages - FP in the high school curriculum - FP as a stepping stone to other CS topics - FP and Philosophy *** Best Lectures *** In addition to papers, we request “best lecture” presentations. What is your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. *** Submission *** Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2015 It is expected at at least one author for each submitted paper will attend the workshop. *** Important Dates *** April 7, 2015: Early Registration for TFP closes April 27, 2015: Submission deadline for draft TFPIE papers and abstracts May 3 2015: Notification of acceptance for presentation ?? (Probably May 22 2015): Registration for TFPIE closes - as does late registration for TFP June 2, 2015: Presentations in Sophia-Antipolis, France July 7, 2015: Full papers for EPTCS proceedings due. September 1, 2015: Notification of acceptance for proceedings September 22, 2015: Camera ready copy due for EPTCS Submission of an abstract implies no obligation to submit a full version; abstracts with no corresponding full versions by the full paper deadline will be considered as withdrawn.

1 0

Haskell Weekly News
by Kim-Ee Yeoh 05 Mar '15

05 Mar '15

*Top picks:* Jasper Van der Jeugt <http://jaspervdj.be/posts/2015-02-24-lru-cache.html> shows how you can write an intuitive, obviously correct LRU cache perfectly polymorphic in both the key and value types of the cache lookup function. (Reddit discussion.) <http://www.reddit.com/r/haskell/comments/2wz4tj/writing_an_lru_cache_in_has…> Core is broken! Well, no, ticket 9858 <https://ghc.haskell.org/trac/ghc/ticket/9858> reported previously is still open, and it's about translating an exotic species of Haskell into Core. But Javran Cheng <https://ghc.haskell.org/trac/ghc/ticket/10121> found out that the documented specification of Core's operational semantics is incomplete. Neil Mitchell <http://neilmitchell.blogspot.com/2015/02/making-withsocketsdo-unnecessary.h…> removes the error-prone wart of withSocketsDo <http://hackage.haskell.org/package/network-2.6.0.2/docs/Network.html#v:with…> in Windows network programming. Moving in for the kill is the triple combo of evaluate, NOINLINE, and unsafePerformIO. (Reddit discussion.) <http://www.reddit.com/r/haskell/comments/2x7js6/making_withsocketsdo_unnece…> Can you write a sorting algorithm? Can you write a fancy sorting algorithm? Can you write a sorting algorithm so fancy it hides a subtle bug? Can you write a sorting algorithm so fancy that it hides a bug so subtle <https://github.com/timjb/haskell-timsort/commit/d9c3e1e454c7d338320f8c2aa12…> that it evades even QuickCheck because the smallest testcase is 2^49 big? But the good news is that QuickCheck doesn't see any regression in the bugfix. (Hacker News discussion.) <https://news.ycombinator.com/item?id=9100107#up_9112425> The consequence of misspelling pragmas <https://ghc.haskell.org/trac/ghc/ticket/10106>, Or: when stumped on a compile error, turn on -Werror to see if you aren't missing something obvious. *Quote of the week:*garry__cairns <https://twitter.com/garry__cairns/status/571087073739976704>: The trouble with learning #haskell is the more I expose myself to it the more I dislike what I have to work with to pay the bills. *Repo of the week: *Kalium <https://github.com/int-index/kalium>: Turn Pascal <https://int-index.github.io/kalium/examples.html> into Haskell -- Kim-Ee

1 0

Haskell 2015: 2nd Call for Papers
by Ben Lippmeier 04 Mar '15

04 Mar '15

===================================================================== ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2015 Vancouver, Canada, 3-4 September 2015, directly after ICFP http://www.haskell.org/haskell-symposium/2015 ===================================================================== ** The Haskell Symposium has an early track this year ** ** See the Submission Timetable for details. ** The ACM SIGPLAN Haskell Symposium 2015 will be co-located with the International Conference on Functional Programming (ICFP 2015) in Vancouver, Canada. The Haskell Symposium aims to present original research on Haskell, discuss practical experience and future development of the language, and to promote other forms of denotative programming. Topics of interest include: * Language Design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts. Papers in the latter three categories need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementors, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. More advice is available via the Haskell wiki: (http://wiki.haskell.org/HaskellSymposium/ExperienceReports) Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. In addition, we solicit proposals for: * System Demonstrations, based on running software rather than novel research results. These proposals should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. Travel Support: =============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://pac.sigplan.org) Proceedings: ============ Accepted papers will be included in the ACM Digital Library. Authors must grant ACM publication rights upon acceptance (http://authors.acm.org/main.html) Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Accepted proposals for system demonstrations will be posted on the symposium website, but not formally published in the proceedings. All accepted papers and proposals will be posted on the conference website one week before the meeting. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Submission Details: =================== Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines (http://www.acm.org/sigs/sigplan/authorInformation.htm) The text should be in a 9-point font in two columns. The length is restricted to 12 pages, except for "Experience Report" papers, which are restricted to 6 pages. Papers need not fill the page limit -- for example, a Functional Pearl may be much shorter than 12 pages. Each paper submission must adhere to SIGPLAN's republication policy, as explained on the web. Demo proposals are limited to 2-page abstracts, in the same ACM format as papers. "Functional Pearls", "Experience Reports", and "Demo Proposals" should be marked as such with those words in the title at time of submission. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. A link to the paper submission system will appear on the Haskell Symposium web site closer to the submission deadline. Submission Timetable: ===================== Early Track Regular Track System Demos ---------------- ------------------- --------------- 13th March Paper Submission 1st May Notification 19th May Abstract Submission 22nd May Paper Submission 5th June Resubmission Demo Submission 26th June Notification Notification Notification 19th July Final papers due Final papers due Deadlines stated are valid anywhere on earth. In this iteration of the Haskell Symposium we are trialling a two-track submission process, so that some papers can gain early feedback. Papers can be submitted to the early track on 13th March. On 1st May, strong papers are accepted outright, and the others will be given their reviews and invited to resubmit. On 5th June early track papers may be resubmitted, and are sent back to the same reviewers. The Haskell Symposium regular track operates as in previous years. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Program Committee: =================== Mathieu Boespflug - Tweag I/O Edwin Brady - University of St Andrews Atze Dijkstra - Utrecht University Tom DuBuisson - Galois Torsten Grust - University of Tuebingen Patrik Jansson - Chalmers University of Technology Patricia Johann - Appalachian State University Oleg Kiselyov - Tohoku University Edward Kmett - McGraw Hill Financial Neelakantan Krishnaswami - University of Birmingham Ben Lippmeier (chair) - Vertigo Technology Hai (Paul) Liu - Intel Labs Garrett Morris - University of Edinburgh Dominic Orchard - Imperial College London Matt Roberts - Macquarie University Tim Sheard - Portland State University Joel Svensson - Indiana University Edsko de Vries - Well Typed =====================================================================

1 0

ANN: ZuriHac 2015: registration is open
by Alexander Bernauer 04 Mar '15

04 Mar '15

Hi everybody, it is my pleasure to announce that the registration for ZuriHac 2015 <https://wiki.haskell.org/ZuriHac2015> is open now. If you want to participate in this year's Haskell Hackathon in Zurich, please fill out this form <http://goo.gl/forms/L24NgFRvCw>. Make sure to wait for a confirmation email afterwards before booking. The event can only host around 90 participants. We will confirm registrations at a first come first served basis. Please spread the word. Hope to see you soon! Alex

1 0

Re: [Haskell-cafe] [Haskell] Constraint Satisfaction Problem
by Henning Thielemann 04 Mar '15

04 Mar '15

On Wed, 4 Mar 2015, K Sai Anirudh wrote: > Hello, > > I tried to solve simple constraint satisfaction problem. This is my code " http://pastebin.com/VAaRYSEA " . > This gives solution for present list of domains, but when I change the domain of 'd' in the list 'ld' then I > get error. I think the error is in line 52. I indexed the first value, but I tried filtering the results > where all the variables are assigned and I get error. I think this fits better to Haskell Cafe <haskell-cafe(a)haskell.org> where I send this reply, too.

1 0

Help needed
by S J Rajath Krishna 04 Mar '15

04 Mar '15

I am a newbie to contributing to open source.I need help or the procedure for the following. 1.Replying to a thread2.Creating an account with the forum that will help me get started off for GSOC 2015. I apologize if this is not the right forum to be posting this, please direct me to the right forum. Thanks,S J Rajath Krishna

2 1

Re: [Haskell-cafe] Hackage and Free Software
by Mike Meyer 04 Mar '15

04 Mar '15

On Sat, Feb 28, 2015 at 11:27 AM, fr33domlover <fr33domlover(a)riseup.net> wrote: > Hello haskellers! > I'd like to make a suggestion: have Hackage accept only packages released under > free software licenses. Anything that excludes software that we could use, or otherwise discourages people from making software available to the community, is a bad idea. A restriction to OSF-approved licenses would exclude anything released under a Creative Commons license, since the OSF doesn't list those, which makes sense as they aren't "software licences" per se. And your restriction of "released under a license" would exclude public domain software - at least in countries that recognize such a thing. Yes, these are nits, but these are nits that could cause someone to decide not to put software that is otherwise perfectly acceptable on Hackage. > Actually the all-rights-reserved tag in Hackage [1] has only two packages > tagged by it - the dummy no-op project HNop, and another package whose COPYING > file contains a broken link and whose README says "BSD style license". This is a general problem on any site that offers downloads with a license type tag. What happens if the selected license tag and the included license have different rights? My suspicion is that if it went to court, you could justify using it under either license, meaning that such things are effectively dual licensed. We might make add a statement making that explicit. In particular, an "all-rights-reserved" tag implies that you may have to ask someone's permission to even download the package from Hackage, so it doesn't make a lot of sense. Given that - with the dual license interpretation - it effectively isn't used, removing it might make sense. Or renaming it to "other not listed" may be more appropriate. <mike

5 9

Re: [Haskell-cafe] Hackage and Free Software
by Mike Meyer 04 Mar '15

04 Mar '15

On Mon, Mar 2, 2015 at 3:36 PM, fr33domlover <fr33domlover(a)riseup.net> wrote: > On 2015-02-28 > Mike Meyer <mwm(a)mired.org> wrote: > > > > > There are open source projects that are systematically excising GPL'ed > > software because of the problems it shares with ShareAlike licenses. > Should > > we disallow the GPL because some people have problems with it? > > > > Making Hackage better to help users sort out which licenses they are > > willing to accept in their project - which I personally would like to do > on > > a project-by-project basis! - is a solution to these problems. > Restricting > > the licenses that are acceptable on Hackage to meet some arbitrary set of > > criteria is a knee-jerk. > The restrictions aren't arbitrary at all. They're based on ethics. On > Software > freedom. > Until you've got an objective set of ethics - or a definition of "software freedom" - that everyone accepts, that's just a long-winded way of saying "arbitrary". Here's a suggestion: We can talk about this forever, because there seem to > be > no official guidelines to really discuss. Why don't we put clear > guidelines at > hackage.haskell.org ? If these guidelines would be "proprietary software > allowed", then there's a point to discuss. But if the guideline requires > certain tagging - currently all the license tags except > all-rights-reserved are > free software licenses - maybe the problem is already solved. > Not quite. "OtherLicense" is an accepted license tag, and I take it to mean I can use any license I want. If you're going to place a restriction on the license types beyond "use one of our tags" (and if you disallow the otherLicense tag, then I'd say that's an arbitrary restriction), then you should either define the terms in it, or choose terms that are well defined. "free software" is so ill defined that gnu.org has to explain what they mean by "free software" (https://www.gnu.org/philosophy/free-sw.html) They even point out that there are open source software licenses that don't meet their definition of free ( https://www.gnu.org/philosophy/open-source-misses-the-point.html) Their definition of proprietary as "not free" makes software licensed under such licenses proprietary, though that's certainly not common usage. So just saying "only free software licenses" or "no proprietary software" would make matters worse, not better, because those terms have multiple meanings in common use. And that makes them not only arbitrary, but vague.

4 4

Re: [Haskell-cafe] Hackage and Free Software
by Mike Meyer 03 Mar '15

03 Mar '15

On Tue, Mar 3, 2015 at 3:19 AM, fr33domlover <fr33domlover(a)riseup.net> wrote: > On Mon, 2 Mar 2015 16:27:53 -0600 > Mike Meyer <mwm(a)mired.org> wrote: > > Until you've got an objective set of ethics - or a definition of "software > > freedom" - that everyone accepts, that's just a long-winded way of saying > > "arbitrary". > Indeed there is an objective clear definition: > http://www.gnu.org/philosophy/free-sw.html Applying that definition may be objective, but not everyone agrees that it's a correct definition of free software, which makes it a subjective definition. > > Not quite. "OtherLicense" is an accepted license tag, and I take it to mean > > I can use any license I want. If you're going to place a restriction on the > > license types beyond "use one of our tags" (and if you disallow the > > otherLicense tag, then I'd say that's an arbitrary restriction), then you > > should either define the terms in it, or choose terms that are well > > defined. "free software" is so ill defined that gnu.org has to explain what > > they mean by "free software" ( https://www.gnu.org/philosophy/free-sw.html) > > They even point out that there are open source software licenses that don't > > meet their definition of free ( > > https://www.gnu.org/philosophy/open-source-misses-the-point.html) Their > > definition of proprietary as "not free" makes software licensed under such > > licenses proprietary, though that's certainly not common usage. > "Open source misses the point" talks about the open source movement - it > doesn't say the BSD, MIT or Apache are not free software licenses. They are! > gnu.org provides a definition of free software, which makes it quite well > defined. There's even a list of licenses. While the BSD, MIT and Apache licenses are free, the GNU license list (https://www.gnu.org/philosophy/license-list.html#NonFreeSoftwareLicenses) provides a long list of open source licenses that aren't free. Some of them aren't free because they are truly noxious, some aren't free because they are poorly written, and some aren't free because the developers restrictions they feel are reasonable, but violate that letter if not the spirit of that definition. > There is nothing arbitrary about it - in the same way the law that puts > murderers in prison isn't arbitrary. It's based on ethics: the value of human > life. Free software is similarly based on the value people's freedom to control > their computing, know what they run and be able to adapt and spread it. Yes, but not everyone agrees to something you would think would be clearcut, like the value of a human life. For instance, some cultures feel that giving your own life for the good of your religion is the best thing you can do with it, and think nothing of taking away some non-believers life for that cause. And in other cultures, your life isn't yours but the states, and you don't have the right to end it yourself. Since there's such broad disagreement on the value of a human life, then it should be no surprise that people disagree on an idea as recent as "free software". For instance, I find it a bit ironic that a defintion of "free software" puts restrictions on derived works that the original author doesn't have to abid by. > > So just saying "only free software licenses" or "no proprietary software" > > would make matters worse, not better, because those terms have multiple > > meanings in common use. And that makes them not only arbitrary, but vague. > The FSF's definition is the only definition I know of. If people understand it > in a different way, this only strengthens my point: make it official and > explain the details and rules, so people do understand what free software is. > If hackage.haskell.org explains this, there will be nothing vague anymore. Pointing to an external definition is certainly an acceptable way to clear up the issue of the meaning of the phrase. However, I object to any definition that excludes open source licenses that would otherwise be useable under the otherLicnese tag for reasons I find capricious (i.e - any license with a "no commercial use" clause is excluded, and the lovely "must use for good" clause in the JSON license causes it to be excluded). The OSI's definition of open source doesn't have any of those problems. How about using it: http://opensource.org/definition <mike

1 0

A Proposed Law for Foldable?
by Gershom B 03 Mar '15

03 Mar '15

For a long time, many people, including me, have said that "Foldable has no laws" (or Foldable only has free laws) -- this is true, as it stands, with the exception that Foldable has a non-free law in interaction with Traversable (namely that it act as a proper specialization of Traversable methods). However, I believe that there is a good law we can give for Foldable. I earlier explored this in a paper presented at IFL 2014 but (rightfully) rejected from the IFL post-proceedings. ( http://gbaz.github.io/slides/buildable2014.pdf) That paper got part of the way there, but I believe now have a better approach on the question of a Foldable law -- as sketched below. I think I now (unlike in the paper) can state a succinct law for Foldable that has desired properties: 1) It is not "free" -- it can be violated, and thus stating it adds semantic content. 2) We typically expect it to be true. 3) There are no places where I can see an argument for violating it. If it pans out, I intend to pursue this and write it up more formally, but given the current FTP discussion I thought it was worth documenting this earlier rather than later. For simplicity, I will state this property in terms of `toList` although that does not properly capture the infinite cases. Apologies for what may be nonstandard notation. Here is the law I think we should discuss requiring: * * * Given Foldable f, then forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a --> a `elem` toList x * * * Since we do not require `a` to be of type `Eq`, note that the `elem` function given here is not internal to Haskell, but in the metalogic. Furthermore, note that the use of parametricity here lets us make an "end run" around the usual problem of giving laws to Foldable -- rather than providing an interaction with another class, we provide a claim about _all_ functions of a particular type. Also note that the functions `g` we intend to quantify over are functions that _can be written_ -- so we can respect the property of data structures to abstract over information. Consider data Funny a = Funny {hidden :: a, public :: [a]} instance Foldable Funny where foldMap f x = foldMap f (public x) Now, if it is truly impossible to ever "see" hidden (i.e. it is not exported, or only exported through a semantics-breaking "Internal" module), then the Foldable instance is legitimate. Otherwise, the Foldable instance is illegitimate by the law given above. I would suggest the law given is "morally" the right thing for Foldable -- a Foldable instance for `f` should suggest that it gives us "all the as in any `f a`", and so it is, in some particular restricted sense, initial among functions that extract as. I do not suggest we add this law right away. However, I would like to suggest considering it, and I believe it (or a cleaned-up variant) would help us to see Foldable as a more legitimately lawful class that not only provides conveniences but can be used to aid reasoning. Relating this to adjointness, as I do in the IFL preprint, remains future work. Cheers, Gershom

8 19