- Haskell-Cafe - Haskell.org

Munich Haskell Meeting, 2018-09-24 @ 19:30
by Leah Neukirchen 22 Sep '18

22 Sep '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 24 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.6.1 released
by Herbert Valerio Riedel 22 Sep '18

22 Sep '18

Hello everyone, Here's an addendum to the announcment as it ommitted an important detail: GHC 8.6.1 is only guaranteed to work properly with tooling which uses lib:Cabal version 2.4.0.1 or later. As such, GHC 8.6.1 works best with `cabal-install` 2.4.0.0 or later; please upgrade to `cabal-install` 2.4.0.0 if you haven't already. Note that cabal-install 2.4 supports all GHC versions back till GHC 7.0.4 and we also strongly recommend to use the latest available stable release of `cabal` even with older GHC releases as bugfixes and improvements aren't always backported to older Cabal releases as well as to be able to benefit from recently added CABAL format features[8] (or be able to access package releases on Hackage[9] which rely on those features) which require recent enough versions of Cabal as well. Note that binaries aren't available on cabal's download page[1] yet. If you're on Ubuntu or Debian, you can get a compiled cabal-install 2.4 `.deb` package via Apt from - https://launchpad.net/~hvr/+archive/ubuntu/ghc or - http://downloads.haskell.org/debian/ respectively. Binary versions for macOS and Windows are also expected to become available via [2] and [3] soon (and also at [1]). In the meantime, if you already have GHC 7.10 or later (together with a compatible `cabal` executable) installed, you can easily install cabal 2.4 yourself from Hackage[9] by invoking cabal install cabal-install-2.4.0.0 and making sure that the resulting `cabal` executable is accessible via your $PATH; you can check with `cabal --version` which should emit something along the lines of $ cabal --version cabal-install version 2.4.0.0 compiled using version 2.4.0.1 of the Cabal library Finally, the Haskell Platform[4] release for GHC 8.6.1 should be available soon as well which provides yet another recommended "standard way to get GHC and related tools"[5] in a uniform way across multiple operating systems. See [4] and [5] for more details about the standard Haskell Platform distribution. [1]: https://www.haskell.org/cabal/download.html [2]: https://haskell.futurice.com/ [3]: https://hub.zhox.com/posts/chocolatey-introduction/ [4]: https://www.haskell.org/platform/ [5]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009379.html [6]: https://launchpad.net/~hvr/+archive/ubuntu/ghc [7]: http://downloads.haskell.org/debian/ [8]: https://cabal.readthedocs.io/en/latest/file-format-changelog.html [9]: http://hackage.haskell.org/ -- Herbert On 2018-09-21 at 20:57:02 -0400, Ben Gamari wrote: > Hello everyone, > > The GHC team is pleased to announce the availability of GHC 8.6.1, the > fourth major release in the GHC 8 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.1 > > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a > number of exciting features. These most notably include: > > * A new deriving mechanism, `deriving via`, providing a convenient way > for users to extend Haskell's typeclass deriving mechanism > > * Quantified constraints, allowing forall quantification in constraint contexts > > * An early version of the GHCi `:doc` command > > * The `ghc-heap-view` package, allowing introspection into the > structure of GHC's heap > > * Valid hole fit hints, helping the user to find terms to fill typed > holes in their programs > > * The BlockArguments extension, allowing the `$` operator to be omitted > in some unambiguous contexts > > * An exciting new plugin mechanism, source plugins, allowing plugins to > inspect and modify a wide variety of compiler representations. > > * Improved recompilation checking when plugins are used > > * Significantly better handling of macOS linker command size limits, > avoiding linker errors while linking large projects > > * The next phase of the MonadFail proposal, enabling > -XMonadFailDesugaring by default > > A full list of the changes in this release can be found in the > release notes: > > https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.… > > Perhaps of equal importance, GHC 8.6 is the second major release made > under GHC's accelerated six-month release schedule and the first set of > binary distributions built primarily using our new continuous > integration scheme. While the final 8.6 release is around three weeks > later than initially scheduled due to late-breaking bug reports, we > expect that the 8.8 release schedule shouldn't be affected. > > Thanks to everyone who has contributed to developing, documenting, and > testing this release! > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > 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. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page https://www.haskell.org/ghc/ > GHC developers' home page https://ghc.haskell.org/trac/ghc/ > Haskell home page https://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > https://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > https://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > https://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 #haskell on IRC, too: > > https://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > https://www.haskell.org/ghc/reportabug

1 0

Algebraic Effects?
by Viktor Dukhovni 21 Sep '18

21 Sep '18

I picked up Haskell fairly recently, as a "better imperative programming language" to implement highly concurrent code to survey DNSSEC and DANE adoption on the Internet. The results are great, I got a DNS library, network and TLS stack that provide effortless concurrency, and a decent interface to Postgres in the form of the Hasql package and performance is excellent. But I'm still a novice in functional programming, with much to learn. So it is only this week that I've started to read about Algebraic effects, and I curious how the Haskell community views these nowadays. If this is a toxic topic raised by newbies who should just Google past discussions instead, feel free to say so... Does the below thread still sum up the situation: https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we_use_effect_han… I see Haskell now also has an Eff monad. Is it widely used? Efficient? Are there other Haskell libraries that build on it as a foundation? One potential advantage that comes to mind with Effects is that the exceptions raised by a computation can enter its signature and it becomes less likely that a library will leak unexpected exception types from its dependencies to its callers if the expected exceptions are explicit in the signatures and checked by the type system. For example, a while back the Haskell Network.DNS library leaked exceptions from a parser library that was an internal implementation detail, and my code had rare crashes on malformed DNS packets, since I did not expect or handle that exception. -- Viktor.

6 8

Origin of monad transformers (was: Algebraic Effects?)
by Olaf Klinke 21 Sep '18

21 Sep '18

> The only monads with distributive laws are in Data.Distributive, and > they're all isomorphic to (->) e for some e. So that's effectively > ReaderT. That is true for this particular signature of distributive law, and I find this a fascinating result. Especially because there are Haskell terms witnessing this categorical fact. In [1, Theorem 2.4.2] it is stated (as I understand it) that if two monads H and K have a distributive law, then the first is a functor on the Kleisli category of the second while the second is a functor on the Eilenberg-Moore category of the first. In the same paper, Section 4 describes monads on Set (including e.g. trees, bags, Maybe) which distribute over all commutative monads. But maybe one does not need such heavy categorical machinery to describe where monad transformers in Haskell come from. Consider the following. There are at least three kinds of monad transformers t in mtl: (1) t m a = m (t' a) for some monad t' (e.g. ExceptT) (2) t m a = t' (m a) for some monad t' (e.g. ReaderT) (3) t m a = g (m (f a)) for some functors g and f. (e.g. StateT) Only (2) is of the Data.Distributive kind, but all three can be unified under the following scheme: Lemma: If F ⊣ G is an adjunction where F: C → D and G: D → C are functors, and if M: D → D is a monad on D, then G∘M∘F is a monad. Proof: One can factor M through the Kleisli category of M L ⊣ R where L: D → Kleisli(M) and R: Kleisli(M) → D. Since adjoints compose, we have L∘F ⊣ G∘R and G∘R∘L∘F = G∘M∘F. q.e.d. There is another interesting paper [2] showing that for certain class of monads, checking the conditions for a distributive law is easier than the general case. Olaf [1] http://emis.ams.org/journals/TAC/volumes/18/7/18-07.pdf [2] https://doi.org/10.1016/S0022-4049(01)00097-4

1 0

Typeclassopedia for numbers
by Dominik Schrempf 20 Sep '18

20 Sep '18

Hello, the Typeclassopedia[1] lists standard Haskell (algebraic ?) type classes and their relations. I was wondering if a similar construct also exists for numeric type classes (and probably also their instances), since I am always struggling with how, e.g., 'Integral' number are related to 'Fractional' and so on and so forth. Thanks, Dominik [1] https://wiki.haskell.org/Typeclassopedia

2 3

Re: [Haskell-cafe] Parsing LocalTime from Unix seconds
by Olaf Klinke 19 Sep '18

19 Sep '18

Is the result of parsing Unix seconds to LocalTime even well-defined? A LocalTime could be in any time zone, while Unix epoch is relative to a certain time-point in UTC. Hence the parse result must depend on what time zone the LocalTime is referring to. Olaf

6 7

Call for lightning talks and participation -- Haskell Implementors' Workshop
by Joachim Breitner 19 Sep '18

19 Sep '18

Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop Sunday, 23 September, 2018 https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 The Haskell Implementors Workshop is only one week away! Time to look at our great program at https://icfp18.sigplan.org/track/hiw-2018-papers#program and plan your day! Lightning Talks --------------- Like in the previous years, we will have slots for lightning talks. And because they were so successful last year, we will have more! *Topics* Anything related to Haskell implementations, fun uses of Haskell etc. goes. Feel free to tell us about ongoing work, to entertain, to rant, to stir a debate! (If you ever have been to a security or crypto conference, you might have attended their “rump session”. While there will not be alcohol involved at HIW, I hope that we can still match their creativity and insightful fun.) *Rules* * There are 3 sets of 3 lightning talks. * Sign-up is on day of the event, in person, on paper. No prior registration possible. * Lightning talks are 8 mins or less. If you know that your lightning talk takes less time, please say so, and maybe we can put four lightning talks into the slot. * Lightning talks do not count as peer-reviewed publications and are not published in the conference proceedings. Program Committee ----------------- * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (DFINITY / University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact ------- * Joachim Breitner <joachim(a)cis.upenn.edu> -- Joachim Breitner former post-doctoral researcher http://cis.upenn.edu/~joachim

2 1

Algebraic Effects?
by Olaf Klinke 19 Sep '18

19 Sep '18

> Have distributive laws [1] ever been used for monad composition in > Haskell? After all, two monads with a distributive law compose. > > Till There is the distributive package on Hackage, which at least matches the type of the nLab definition. Many common monad transformers stem from monads that are "universally distributive" in the following sense: If t is a monad transformer, then for all other monads m a function with one of the following types can be defined: t Identity (m a) -> m (t Identity a) m (t Identity a) -> t Identity (m a) For which transformers is this the case? For those where t m a is isomorphic to one of the two types t Identity (m a) m (t Identity a) Examples: distr_Reader :: Functor m => m (r -> a) -> r -> m a distr_Reader = \m -> \r -> fmap ($r) m distr_Writer :: Functor m => (w,m a) -> m (w,a) distr_Writer = \(w,m) -> fmap ((,) w) m distr_Either :: Applicative m => Either e (m a) -> m (Either e a) distr_Either (Left e) = pure (Left e) distr_Either (Right m) = fmap Right m distr_Maybe :: Applicative m => Maybe (m a) -> m (Maybe a) distr_Maybe Nothing = pure Nothing distr_Maybe (Just m) = fmap Just m More generally, two monads distribute when one is an endofunctor on the Kleisli category of the other. (The nLab page says Eilenberg-Moore category, I'm not sure whether the two statements are equivalent.) A morphism in the Kleisli category of m is a function a -> m b. An endofunctor f on the Kleisli category must map such a function to a function f a -> m (f b). For example, kleisli_Maybe :: Applicative m => (a -> m b) -> Maybe a -> m (Maybe b) kleisli_Maybe _ Nothing = pure Nothing kleisli_Maybe k (Just a) = fmap Just (k a) kleisli_Reader :: Functor m => (a -> r -> b) -> m a -> r -> m b kleisli_Reader k x r = fmap (flip k r) x Notice that in the former case we used the Kleisli category of m whereas in the latter case we used the Kleisli category of Reader. The more general picture involves an adjunction and the monad m. This covers StateT and the continuation monad. It is well-known that any adjunction F -| G between two categories gives rise to a monad, namely GF. Suppose F:C->D and G:D->C are functors. The adjuntion says that the hom-sets D(Fa,b) and C(a,Gb) are naturally isomorphic. For the state monad, C = Hask (the category of Haskell types and functions) D = Hask, F = (,) s G = (->) s and the isomorphism of hom-sets is currying and uncurrying between (s,a) -> b and a -> (s -> b). In case of the continuation monad Cont r a = (a -> r) -> r, we have C = Hask, D = Hask^op (Hask with direction of arrows reversed) F a = (a -> r) G b = (b -> r) and the isomorphism of hom-sets is between a -> (b -> r) and b -> (a -> r) where the latter is Hask^op(Fa,b). In the case of StateT, since the intermediate category D is Hask, any functor m is an endofunctor on the intermediate category. I do not recall under which conditions the composite GMF is a monad. Olaf

1 0

natural mergesort in Data.List
by Christian Sternagel 18 Sep '18

18 Sep '18

Dear Cafe, some years ago I formalized the mergesort implementation [1] from http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Data.OldList.html… (as far as I can tell it didn't change since 2012) in the proof assistant Isabelle/HOL [2]. More specifically, I proved its functional correctness (the result is sorted and contains all elements of the input with exactly the same multiplicities) and that it is a stable sorting algorithm. Very recently I also formalized a complexity result in Isabelle/HOL, namely that the number of comparisons is bounded from above by n + n * ⌈log 2 n⌉ for lists of length n. For this proof I had to change the definition of "sequences", "ascending", and "descending" slightly. Now here is my question: Does anyone now of reasons why the current implementation of "sequences" is allowed to produce spurious empty lists in its result? The version I used in my formalization only differs in the following three spots: sequences [x] = [[x]] -- this is the only important change, since sequences [] = [] -- then the result does not contain empty lists instead of sequences xs = [xs] and ascending a as [] = let !x = as [a] in [x] instead of ascending a as bs = let !x = as [a] in x : sequences bs and descending a as [] = [a:as] instead of descending a as bs = (a:as) : sequences bs [1] https://www.isa-afp.org/entries/Efficient-Mergesort.html [2] http://isabelle.in.tum.de/

3 6

Get-together at ICFP about Haskell in K-12 education
by Chris Smith 18 Sep '18

18 Sep '18

Hello Haskell community! I've been floating an idea around about hosting a get-together in St. Louis for anyone interested in Haskell at the K-12 (pre-university) level. Some of you know that this has been a big passion of mine for the last 8 years or so. I'd love to discuss with others while a lot of us are in the same place -- whether you're interested in organized teaching, or just teaching your own kids, or just curious about the idea. I've put together this form to collect RSVPs and availability. Interest Form <https://docs.google.com/forms/d/e/1FAIpQLSdJPWIMroEyBuqP15ngmZrp0XwwP-C5uuE…> Thanks, Chris Smith

1 2