- Haskell-Cafe - Haskell.org

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

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

06 Oct '15

On Tue, Oct 6, 2015 at 2:40 AM Bardur Arantsson <spam(a)scientician.net> wrote: > > - To use functions like "tryReadMVar", "unsafeShiftR", and > > "atomicModifyIORef'" that are in recent base versions but not older > ones > > (this is a place where CPP use is actually justified) > Well, yeah, new functions don't magically appear in old versions. I > don't anybody expects that :). > Right - they have to be backported, and imply maintenance of multiple branches. Python has been mentioned a couple of times. They did that, backporting functions that mimiced Python 3 functions to later Python 2 versions, which made the tools mentioned possible, or at least more capable. I'll refer those wanting fewer breaking changes to Python. Getting language changes accepted by the PYthon community is *hard*. You need a use case for your change, you need to show that the case can't be handled cleanly by the language as it exists today, that it's common enough to justify the change, and that it won't tempt people to write uglier code than the current solution. If you want to break old code, all those bars get raised - a lot. Or did, anyway, The result of following that was the Python 2/Python 3 split, which I don't think anybody thought was a good thing. Unavoidable, maybe - Python 3 had to break backwards compatibility, so they cleaned up everything along the way, and created tools to migrate code, and committed to maintaining both versions for an extended period of time. And the community was pretty badly splintered by this. The one thing I think they got right is documenting the language change process with the entire PEP process. We seem to have wiki pages, with no editorial oversight, and pages show up in google searches after they've been incorporated into the language in a different form. Not quite as good a thing.

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal
by Doug McIlroy 05 Oct '15

05 Oct '15

Sorry for the premature send. The incomplete sentence was: 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. doug

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by mantkiew＠gsd.uwaterloo.ca 05 Oct '15

05 Oct '15

I loved the statement made by Ryan Trinkle in his recent talk [1]: "since we cannot predict all the changes needed the future, we must have an architecture that will support any change" (it's roughly like that, not an exact quote, about 4minutes in). Having to use IFDEFs is a sign that the language itself is not expressive enough to deal with these kinds of changes and therefore it's not having the right "architecture". Is Backpack going to provide the necessary support, (e.g., ability to mix in package fragments with extensions instead of making breaking changes)? What kind of language features are still missing? Anyway, mistakes were made in the past, because had we known any better we would have done better. Nothing should prevent us from fixing mistakes. Regarding IFDEFS, all of them disappeared from my code once I used transformers-compat and mtl-compat. ‎Also the trick with import Prelude worked-you just have to list what you hide instead of what you import (which is weird...). -- Michał [1] http://www.infoq.com/presentations/functional-techniques-complexity On Mon, Oct 5, 2015 at 2:34 PM, Gregory Collins <greg(a)gregorycollins.net> wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb(a)gmail.com> wrote: >> >> My understanding of the argument here, which seems to make sense to me, is >> that the AMP already introduced a significant breaking change with regards >> to monads. Books and lecture notes have already not caught up to this, by >> and large. Hence, by introducing a further change, which _completes_ the >> general AMP project, then by the time books and lecture notes are all >> updated, they will be able to tell a much nicer story than the current one? > > > This is a multi-year, "boil the ocean"-style project, affecting literally > every Haskell user, and the end result after all of this labor is going to > be... a slightly spiffier bike shed? > > Strongly -1 from me also. My experience over the last couple of years is > that every GHC release breaks my libraries in annoying ways that require CPP > to fix: > > ~/personal/src/snap λ find . -name '*.hs' | xargs egrep > '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l > 64 > > > As a user this is another bikeshedding change that is not going to benefit > me at all. Maintaining a Haskell library can be an exasperating exercise of > running on a treadmill to keep up with busywork caused by changes to the > core language and libraries. My feeling is starting to become that the > libraries committee is doing as much (if not more) to cause problems and > work for me than it is doing to improve the common infrastructure. > > G > -- > Gregory Collins <greg(a)gregorycollins.net> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

ANN: HaRe 0.8 - The Haskell Refactorer
by Alan & Kim Zimmerman 05 Oct '15

05 Oct '15

I'm pleased to announce the release of HaRe 0.8, available on hackage [1] What's new? =========== Everything, and nothing. Everything in the sense that it has been completely reworked internally to make use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint [3] library. Nothing in the sense that the functionality in this version is/should be identical to that in 0.7.2.8 Limitations =========== HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. Compiling HaRe with 7.10.2 and then using it against projects using an earlier compiler will not work, as HaRe needs to be able to invoke GHC to the type checker stage on the project using GHC 7.10.2. What is it? =========== HaRe makes changes to working code, so that it still works once the change is made. Refactorings it can do are * demote Take a declaration from the level where it is defined and move it down to the place where it is used. This only works if it is used in one place only. * dupdef Duplicate a definition with a new name. * iftocase Convert an if declaration to a case declaration. * liftOneLevel Move a declaration one level up, adding parameters as needed to pass in locally declared variables. * liftToTopLevel Move a declaration to the top level, adding parameters as needed to pass in locally declared variables. * rename Change a name throughout the project. This makes use of the GHC renamed source so will not change other names that just happen to be lexically identical, but are in fact different names. It currently has an emacs integration only, assistance in supporting other environnments welcome. [1] https://hackage.haskell.org/package/HaRe [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations [3] https://hackage.haskell.org/package/ghc-exactprint Alan

4 6