May 2016 - Haskell-Cafe

Dev/tools/git/Haskell role in London
by Don Stewart 24 May '16

24 May '16

https://donsbot.wordpress.com/2016/05/24/haskell-devtoolsgit-role-at-standa… I have a new role at SCB this time in the "Modelling Infrastructure" team to work on our Haskell-based continuous integration and testing system on top of git. This is a London role. More details in the linked post.

1 0

Stack build with GHC 8?
by David Turner 24 May '16

24 May '16

Hi, My name appears in the Stackage GHC 8 mega-issue [ https://github.com/fpco/stackage/issues/1476] and I'd like to upgrade my packages. I suspect it's just a case of relaxing the upper bound on base to <4.10 but I'd quite like to check that this does, in fact, work. However I'm not sure how to go about doing this since there don't yet seem to be any stackage snapshots that use GHC 8. What's the best way to get around this? Cheers, David

2 1

[ANNOUNCE] GHC 8.0.1 is available!
by Ben Gamari 23 May '16

23 May '16

=============================================== The Glasgow Haskell Compiler -- version 8.0.1 =============================================== The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including, * A more refined interface for implicit call-stacks, allowing libraries to provide more helpful runtime error messages to users * The introduction of the DuplicateRecordFields language extension, allowing multiple record types to declare fields of the same name * Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports * A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches * More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools * Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators * The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings * Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets * A greatly improved user's guide, with beautiful and modern PDF and HTML output * Introduction of type application syntax, reducing the need for proxies * More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor * Support for injective type families and recursive superclass relationships * An improved generics representation leveraging GHC's support for type-level literals * The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level * ...and more! A more thorough list of the changes included in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.… As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0 Please let us know if you encounter anything missing or unclear on this page. This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve. How to get it ~~~~~~~~~~~~~ Both the source tarball and binary distributions for a wide variety of platforms are available at, http://www.haskell.org/ghc/ Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, can be found on the GHC wiki http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

5 4

Help moving a bounds check into a case branch
by David Feuer 22 May '16

22 May '16

Sorry for the terrible subject line, but I'm a but stuck here. A couple days ago I overhauled Data.Sequence.splitAt, greatly improving its performance. You can see the new implementation at https://github.com/haskell/containers/blob/e8b1f664a631e3795dfd14f2d8c2b39c… . There's one spot where I'm still stuck, however. Much like the original implementation, I check that the splitting index is before the end of the sequence (to ensure correctness). I go further, in fact, checking that the splitting index is positive, in order to avoid allocating a new tree-top in a trivial split. Logically, this check should be moved into the Deep case branch in splitTreeE, to avoid pattern matching on the top of the tree twice and performing redundant comparisons. However, when I make that move, the split/append benchmark gets worse. When I looked at the Core, it seemed that I confused GHC somehow. I ended up with a join point taking an extra argument that it totally ignored. I can fix that benchmark by marking the splitTreeMiddleE function INLINE, but then the zipWith benchmark went screwy. Unless I can get non-fragile results, I'm just going to accept the redundant case match. If anyone has any ideas, please let me know. Thanks, David Feuer

1 0

Re: [Haskell-cafe] TDNR without new operators or syntax changes
by Jeremy . 22 May '16

22 May '16

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.

3 2

Going insane over overlapping instances
by Brian Hurt 22 May '16

22 May '16

This is driving me nuts. So I have a type class HasStructParser I've defined. Details are irrelevant except that if you have HasStructParser defined, then ToJSON is also defined. So I have: instance HasStructParser s => ToJSON s where ... But now, any type that defines ToJSON any other way causes an Overlapping Instances error to happen- the conflict being between the real ToJSON implementation and the one deriving from HasStructParser- this despite the fact that there is no implementation for HasStructParser for the given type. Now, I don't want to allow Overlapping Instances because if there are *real* overlapping instances, I want that to be an error. For instance, if a structure did implement HasStructParser and some other implementation of ToJSON, I want to know. I suppose I could go: newtype JSON a = JSON a instance HasStructParser s => ToJSON (JSON s) where ... But this strikes me as being ugly- now I have to add pointless JSON constructors everywhere I want to convert to (or from) JSON. And this also pollutes my type signatures all over the place- now I can't write a servant endpoint type like: :<|> "foo" :> "bar" :> Get '[JSON] [Foo] I have to write: :<|> "foo" :> "bar" :> Get '[JSON] [JSON Foo] And, of course, if I want to have multiple different types of outputs, now we're off to the races. So my question is, is there a way to do this without throwing the baby out with the bath water (turning on overloaded instances) or being seriously ugly? Or am I just screwed? Brian

2 1

Representation of 3-D objects in non-continuous space
by Michael Litchard 22 May '16

22 May '16

I've been poking at the problem that I've talked about in the following threads. https://groups.google.com/forum/#!searchin/haskell-cafe/michael$20litchard|… https://groups.google.com/forum/#!searchin/haskell-cafe/michael$20litchard|… And my misguided conclusions here https://groups.google.com/forum/#!topic/haskell-cafe/PMtYhVQ5nNQ I'm trying to write a clone in haskell of the space-system implemented in http://swmud.org. The biggest error in my thinking so far is assuming I could do without spatial extent. Nope, these objects in space will have to have spatial extent. So no octree for me. The advice and comments from the first two threads prompted me to investigate R-trees. I could only find specifics about how to describe 2-D. Until I found this paper on layered R-Trees. http://www.isprs.org/proceedings/XXXIII/congress/part4/1216_XXXIII-part4.pdf This looks like what I want. Here's my re-formulation of the criteria: (1) Objects in space will be either ships that can move or stationary things like non-moving game-controlled ships, space-stations , moons and planets. (2) Objects will have spatial extent. Will use bounding volumes to help determine collisions. (3) Space is non-continuous (4) Movement happens by setting a destination vector and a speed. There's no steering exactly, but you can change destination while moving, slow down or stop suddenly. (5) Represent this space with a layered R-tree, This tree will at most have say, 200-300 objects in it, most of which could be moving around in this space. It's the number of objects that have me wondering if layered r-tree might be too heavy-weight. If so, Any links to R-tree variants that include bounding volumes? I could only find ones with bounding boxes.

1 1

ANNOUNCE: testbench-0.1.0.0
by Ivan Lazar Miljenovic 22 May '16

22 May '16

I've just released a new library onto Hackage that aims to help you writing comparison-oriented benchmarks by: a) reducing the duplication found when using criterion directly b) let you test your benchmarked values/functions to ensure that they have the same result/satisfy a given predicate c) provide more comparison-oriented output I've written more about it here: https://ivanmiljenovic.wordpress.com/2016/05/23/test-your-benchmarks/ Or you could go straight to the Hackage page here: http://hackage.haskell.org/package/testbench -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Haskell Meetup group in Delhi, India
by Anupam Jain 21 May '16

21 May '16

Hi all, I just started a meetup group for Haskellers in and around Delhi NCR, India. The plan is to organise regular (monthly) meetups, talks, workshops etc for Haskell / FP enthusiasts at all skill levels. Anyone interested is welcome to join at - http://meetu.ps/c/2K4ft/FT8H/f. Also, since we are just getting started, the best way to help right now would be to spread the word! Thanks, Anupam Jain

1 0

ANN: stack-1.1.2
by Emanuel Borsboom 20 May '16

20 May '16

Release notes: - Official FreeBSD binaries are now available <http://docs.haskellstack.org/en/stable/install_and_upgrade/#freebsd> ( #1253 <https://github.com/commercialhaskell/stack/issues/1253>). Major changes: - Extensible custom snapshots implemented. These allow you to define snapshots which extend other snapshots. See #863 <https://github.com/commercialhaskell/stack/issues/863>. Local file custom snapshots can now be safely updated without changing their name. Remote custom snapshots should still be treated as immutable. Behavior changes: - stack path --compiler was added in the last release, to yield a path to the compiler. Unfortunately, --compiler is a global option that is useful to use with stack path. The same functionality is now provided by stack path --compiler-exe. See #2123 <https://github.com/commercialhaskell/stack/issues/2123> - For packages specified in terms of a git or hg repo, the hash used in the location has changed. This means that existing downloads from older stack versions won’t be used. This is a side-effect of the fix to #2133 <https://github.com/commercialhaskell/stack/issues/2133> - stack upgrade no longer pays attention to local stack.yaml files, just the global config and CLI options. #1392 <https://github.com/commercialhaskell/stack/issues/1392> - stack ghci now uses :add instead of :load, making it potentially work better with user scripts. See #1888 <https://github.com/commercialhaskell/stack/issues/1888> Other enhancements: - Grab Cabal files via Git SHA to avoid regressions from Hackage revisions #2070 <https://github.com/commercialhaskell/stack/pull/2070> - Custom snapshots now support ghc-options. - Package git repos are now re-used rather than re-cloned. See #1620 <https://github.com/commercialhaskell/stack/issues/1620> - DESTDIR is filtered from environment when installing GHC. See #1460 <https://github.com/commercialhaskell/stack/issues/1460> - stack haddock now supports --hadock-arguments. See #2144 <https://github.com/commercialhaskell/stack/issues/2144> - Signing: warn if GPG_TTY is not set as per man gpg-agent Bug fixes: - Now ignore project config when doing stack init or stack new. See #2110 <https://github.com/commercialhaskell/stack/issues/2110> - Packages specified by git repo can now have submodules. See #2133 <https://github.com/commercialhaskell/stack/issues/2133> - Fix of hackage index fetch retry. See re-opening of #1418 <https://github.com/commercialhaskell/stack/issues/1418#issuecomment-2176338…> - HPack now picks up changes to filesystem other than package.yaml. See #2051 <https://github.com/commercialhaskell/stack/issues/2051> - “stack solver” no longer suggests —omit-packages. See #2031 <https://github.com/commercialhaskell/stack/issues/2031> - Fixed an issue with building Cabal’s Setup.hs. See #1356 <https://github.com/commercialhaskell/stack/issues/1356> - Package dirtiness now pays attention to deleted files. See #1841 <https://github.com/commercialhaskell/stack/issues/1841> - stack ghci now uses extra-lib-dirs and extra-include-dirs. See #1656 <https://github.com/commercialhaskell/stack/issues/1656> - Relative paths outside of source dir added via qAddDependentFile are now checked for dirtiness. See #1982 <https://github.com/commercialhaskell/stack/issues/1982> - Signing: always use --with-fingerprints ------------------------------ Thanks to all our contributors for this release: - Benno Fünfstück @bennofs <https://github.com/bennofs> - Emanuel Borsboom @borsboom <https://github.com/borsboom> - Levi Notik @levinotik <https://github.com/levinotik> - Michael Sloan @mgsloan <https://github.com/mgsloan> - Michael Snoyman @snoyberg <https://github.com/snoyberg> - Oleg Grenrus @phadej <https://github.com/phadej> - Sebastian Graf @sgraf812 <https://github.com/sgraf812> - Simon Jakobi @sjakobi <https://github.com/sjakobi> - Tim Dysinger @dysinger <https://github.com/dysinger> - Yann Esposito @yogsototh <https://github.com/yogsototh> - Yuji Yamamoto @igrep <https://github.com/igrep> And thanks also to the 150+ contributors to past releases!

1 0