October 2015 - Haskell-Cafe

status and future of haskell98 and haskell2010 packages
by Andrey Chudnov 08 Oct '15

08 Oct '15

Hello, My e-mail was rejected from libraries(a)haskell.org (the official maintenance contact of the two packages in question), so I'm trying my luck here instead. Hoping I can get some answers on the following questions: 1. What is the status of `haskell2010` and `haskell98` packages? Are they supported? Deprecated? In need of new maintainers? 2. Assuming the answer to the previous question is "alive and well", are there any plans to release new versions of those for GHC 7.10 and beyond? Thanks in advance, Andrey

2 1

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Brandon Allbery 08 Oct '15

08 Oct '15

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > Please consider that the the way practical development really happens[2] ...among web developers, who of course are the only real developers? Have you considered that there are developers who are not web developers? The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers. I had heard that the financial users generally refused to have anything to do with the Haskell community. Now I know why. I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers". -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

6 6

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Mark Lentczner 08 Oct '15

08 Oct '15

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > TLDR: To complete the AMP, turn `Monad(return)` method into a > top-level binding aliasing `Applicative(pure)`. > Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. Think of it as Perl 6 or Python 3 for Haskell. - Mark On Tue, Oct 6, 2015 at 1:12 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > (Resending with smaller recipient list to avoid getting stuck in the > moderator queue.) > > On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr(a)gnu.org> > wrote: > >> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: >> > On the libraries I maintain and have a copy of on my computer right >> now: 329 >> >> >> Although this was already pointed out to you in a response to a Tweet of >> yours, I'd like to expand on this here to clarify: >> >> >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. > > Neither AMP or MRP includes a recipe for this in their proposal. AMP got > one post-facto on the Wiki. It turns out that the workaround there didn't > work (we tried it in Cabal and it conflicted with one of the above > requirements.) > > PS: I'm a bit disappointed you seem to dismiss this proposal right away >> categorically without giving us a chance to address your >> concerns. The proposal is not a rigid all-or-nothing thing that >> can't be tweaked and revised. That's why we're having these >> proposal-discussions in the first place (rather than doing blind >> +1/-1 polls), so we can hear everyone out and try to maximise the >> agreement (even if we will never reach 100% consensus on any >> proposal). >> >> So please, keep on discussing! >> > > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. > > What's frustrating is that people don't take a step bad and realize that > they might be in the latter group and should perhaps listen to those in the > former. This doesn't happen, instead we get lots of "C++ and Java so bad > and we don't want to be like them." Haskell is not at risk of becoming C++ > or Java (which are a large improvement compared to the languages came > before them). We're at risk of missing our window of opportunity. I think > that would be a shame, as I think Haskell is a step forward compared to > those languages and I would like to see more software that used be written > in Haskell. > > We've been through this many times before on the libraries list. I'm not > going to win an argument on this mailing list. Between maintaining > libraries you all use and managing a largish team at Google, I don't have > much time for a discussion which approaches a hundred emails and is won by > virtue of having lots of time to write emails. > > -- Johan > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

5 5

quickCheck problem
by Roelof Wobben 08 Oct '15

08 Oct '15

Hello, I have written a function to test if three numbers are the same. Now I want to test my functions by using quickCheck. So I thought to test first if all three are the same. but how can I tell quickcheck that all numbers are the same. and second question : hwo do the test likeif two numbers are the same. I ask this because I try to solve a exercise of the programming Haskell book, IM have read chapter 3 now. Roelof

5 12

Looking for a new maintainer for the template package
by Johan Tibell 07 Oct '15

07 Oct '15

I find myself with too little time to maintain the template package anymore, so I'm hereby announcing that I'm looking for a new maintainer. The template package is a quaint little package for doing Python-style string interpolation. Please email me if you're interested. -- Johan

2 1

Looking for a new maintainer for the network package
by Johan Tibell 07 Oct '15

07 Oct '15

I find myself with too little time to maintain the network package anymore, so I'm hereby announcing that I'm looking for a new maintainer. Since lots of people depend on the network package, the maintainer should probably be someone that values stability. If you want to completely rethink how networking APIs should work in Haskell, this is probably not for you. Please email me if you're interested. -- Johan

1 0

OShack hackathon (offer of help)
by Alexey Shmalko 07 Oct '15

07 Oct '15

Hi! We have the OShack hackathon[1] in Kyiv, Ukraine this weekend. It's a 24-hour hackathon dedicated to Open-Source projects. I with friends want to offer our help of time to any Haskell project that needs it. Just ping me back so we can discuss the details. If you're in Kyiv and want to join our team, we'll be glad to see you! You can also join online. Regards, Alexey Shmalko [1]: http://hackraft.com/hackathon/oshack/

1 0

Re: [Haskell-cafe] Reducing the need for CPP
by Bardur Arantsson 06 Oct '15

06 Oct '15

On 10/06/2015 11:11 AM, Johan Tibell wrote: > It might be enough to just add a NOWARN <warning type> pragma that acts on > a single line/expression. I've seen it in both C++ and Python linters and > it works reasonably well and it's quite general. +1. Simple is good and can hopefully also be backported to older GHC releases. (Provided someone's willing to do said releases, obviously.)

2 1

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 06 Oct '15

06 Oct '15

If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, deadline 31st October 2015. Many thanks, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st October 2015 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 31st October 2015. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Rustom Mody 06 Oct '15

06 Oct '15

On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy <doug(a)cs.dartmouth.edu> wrote: > > littering the code with #ifdefs > > > Bonus points for keeping the #ifdefs centralized > > Littering is the right word. "Bonus" is merely less negative points. > > It is ironic that the beautiful Haskell should progress by > adopting the worst feature of C. #ifdef is a sticking-plaster > for non-portable code. It is inserted at global level, usually > to effect changes at the bottom of the code hierarchy. (Maybe > in Haskell it should be a monad, in competition with IO for > the outermost layer.) > > Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed) > inescapably nonportable code, such as endianity, in compilation > units and #include files in a distinct part of the file system > tree selected by the shell. > > Another trick is to use plain if rather than #if or #ifdef, > and let the compiler optimize away the unwanted side of the > branch. > > > In any event, #ifdef is, as Simon evidently agrees, telling > evidence of non-portability. It is hard to imagine an uglier > "solution" to keeping up with the drip-drip-drip of Haskell > evolution. > > The python 2→3 transition may have caused some pain to some. However it would have been far more difficult if they had not provided tools like 2to3 and six: https://docs.python.org/2/library/2to3.html http://pythonhosted.org/six/ Since the change here is trivial and pervasive why is such a tool not being considered? [Or have I missed the discussion?] In particular we can envisage a tool say 8to10 that has these modes (command-line flags) --portable --readable --info with the idea that - portable is most unreadable (ifdef litter) - readable is not portable -- generate a copy of the whole source tree that will have the changes and not be compatible for ghc < 7.8 This is for those library authors that prefer to maintain a clean code base and hell with earlier ghc versions - info summarizes which files would change and how so that a suitable reorganization of the files/directories can be done prior to the switch This is for those library authors that would like to take the trouble to have a compatibility layer and have code as readable as possible overall [Whether pure is really preferable to return is another matter -- For me one of the strongest criticisms of the python 2→3 switch is this that if they were going to break things anyhow why was the cleanup not more far-reaching? Lets keep this note in these parentheses :-) ]

2 1