January 2018 - Haskell-Cafe

ANN: containers-0.5.11.0
by David Feuer 23 Jan '18

23 Jan '18

We have just released containers version 0.5.11.0. This is the first release since Matt Renaud joined the maintenance team. Matt has focused on documentation, code quality, and testing, and made some substantial contributions in these areas. This release comes with quite a few new functions and instances, written by quite a few different contributors. It also includes a complete overhaul of the sorting machinery in Data.Sequence thanks to Donnacha Oisín Kidney. And Matt Renaud has launched a brand new set of tutorial documentation at https://haskell-containers.readthedocs.io/en/latest/ Many thanks to all the contributors who made this release possible! The complete changelog can be found below. David Feuer Matt Renaud Wren Romano New functions and class instances * Add a `MonadFix` instance for `Data.Sequence`. * Add a `MonadFix` instance for `Data.Tree`. * Add `powerSet`, `cartesianProduct`, and `disjointUnion` for `Data.Set`. (Thanks, Edward Kmett.) * Add `disjoint` for `Data.Set` and `Data.IntSet`. (Thanks, Víctor López Juan.) * Add `lookupMin` and `lookupMax` to `Data.IntMap`. (Thanks, bwroga.) * Add `unzip` and `unzipWith` to `Data.Sequence`. Make unzipping build its results in lockstep to avoid certain space leaks. * Add carefully optimized implementations of `sortOn` and `unstableSortOn` to `Data.Sequence`. (Thanks, Donnacha Oisín Kidney.) Changes to existing functions and features * Make `Data.Sequence.replicateM` a synonym for `replicateA` for post-AMP `base`. * Rewrite the `IsString` instance head for sequences, improving compatibility with the list instance and also improving type inference. We used to have instance IsString (Seq Char) Now we commit more eagerly with instance a ~ Char => IsString (Seq a) * Make `>>=` for `Data.Tree` strict in the result of its second argument; being too lazy here is almost useless, and violates one of the monad identity laws. Specifically, `return () >>= \_ -> undefined` should always be `undefined`, but this was not the case. * Harmonize laziness details for `minView` and `maxView` between `Data.IntMap` and `Data.Map`. Performance improvement * Speed up both stable and unstable sorting for `Data.Sequence` (Thanks, Donnacha Oisín Kidney.) Other changes * Update for recent and upcoming GHC and Cabal versions (Thanks, Herbert Valerio Reidel, Simon Jakobi, and Ryan Scott.) * Improve external and internal documentation (Thanks, Oleg Grenrus and Benjamin Hodgson.) * Add tutorial-style documentation. * Add Haddock `@since` annotations for changes made since version 0.5.4 (Thanks, Simon Jakobi.) * Add a (very incomplete) test suite for `Data.Tree`. * Add structural validity checks to the test suites for `Data.IntMap` and `Data.IntSet` (Thanks to Joachim Breitner for catching an error in a first draft.)

2 1

[ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 21 Jan '18

21 Jan '18

The GHC development team is pleased to announce the first alpha release of the 8.4.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha1 Note that this release drops compatibility with GCC 4.6 and earlier. While we generally try to place as few constraints on system toolchain as possible, this release depends upon the __atomic__ builtins provided by GCC 4.7 and later (see #14244). === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceeded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes in to users hands and allow better feedback on the status of the release. GHC 8.4 is slated to be released in mid-February but, due to technical constraints, we are starting the alpha-release cycle a bit later than planned under the above schedule. For this reason, it would be greatly appreciated if users could put this alpha through its paces to make up for lost time. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

3 4

FRP: Why is Behavior not a Monad?
by martin 20 Jan '18

20 Jan '18

Hello all, it appears to be difficult to define a Monad instance for Behavior and in many (if not all) reactive libraries Behavior is not a Monad. Why is that so? If a Beahvior is conceptionally a function from Time to something, newtype Behavior a = Behavior (Time -> a) then its Monad instance should work like a Reader Monad. Alternatively one can look at the join function join :: Behavior (Behavior a) -> Behavior a. This corresponds to the situation where you switch between Channels on a TV remote controle and each Channel is a behavior of Image. Then join Behavior (Behavior image) should give you the video stream you see on the screen. How can one possibly live without this operation? I assume this has something to do with the actual implementation and not so much with the semantics, because semantically I don't see any problems. So, - why is Behavior not a Monad and - how would you express the TV-remote example without a Monad?

4 3

How to use FRP for Simulation
by martin 20 Jan '18

20 Jan '18

Hello all, the answer to the question "what is FRP good for?" often includes "simulation". I somewhat understand the "reactive" situation, where an FRP system receives Events from the outside world and computes Events to be sent to the outside world. To do so, the computation uses Behaviors which are essentially time-varying states. I also read, that the programmer should not be allowed to literally define Events and Behaviors, or she might end up writing bad prograns which exhibit time or space leaks. She should only be allowed to define transformations. Now in a discrete event simulation (DES) there is a lot of "event stuff" going on and FRP looks like a good paradigm. However, in a simulation nothing comes from the outside world and not much goes to the outside world. There is a simulation result, but it is just a result like any other and doesn't have much to do with Time. A DES is not really a reactive system at all. In DES there is typically a set of initial Events and more events are created as the simulation progresses. I cannot see how this can be done without the power to explicitly create Events. Also these Events point to the "future" and must therefore carry an explicit (simulated) Time, whereas (IIRC) in FRP, Events do not necessarily carry an explicit Time. They just occur, and if you need the time, you look at the clock (a Behavior Time). So what exactly is meant by "FRP is useful for simulation". Does it mean that a DES engine can be written in FRP style or does it mean something else? If one can indeed write a DES engine in FPR style, what is the correct way of thinking about it?

1 0

FRP: how does integration work?
by martin 20 Jan '18

20 Jan '18

Hello all, I am at best half-educated when it comes to FRP, so feel free to direct me to the homework I should do before asking obvious questions. I vaguely remember Paul Hudak talking about integrating a Signal (aka Behavior). Now I have this image in my head, where a Behavior is like vector graphics, except its domain Time and not space. Also I heard the term "late sampling" in conjunction with FRP. Bot ideas make sense to me. So if I look at integration in vector graphics, I might want to get the area between a curve and the x-axis. If I render the curve and then count the pixels between the curve and x-axis, the result will depend on the resolution. With a very low resolution, I'll get a crude approximation of the true area and as I increase the resolution I'll get better approximations and with infinite resolution I'll get the true area. So the result of integration seems to depend on the chosen resolution. Conversely, with pixel graphics, the resolution is fixed right from the start and I cannot not up the resolution at all, at best I could downsample. In FRP I should have something like: newtype Behavior a = Behavior (Time -> a) type Curve = Behavior Double integral :: Curve -> Double -> Curve -- 2nd parameter is the integration constant But what do I get when I take the value of the integral at a given point in time? integralAt :: Time -> Curve -> Double integralAt t curve = let (Behaviour i) = integral curve 0 in i t Nowhere do I mention any (temporal) resolution. How does the integral function know which resoltion to choose?

1 0

Adding packages from within ghci session
by Simon Hafner 20 Jan '18

20 Jan '18

Hello I've been exploring some code via ghci, and I've found myself in this loop: - write some code - figure out I need another package (e.g. mtl for runReaderT) - add package to cabal specification - reload stack ghci - Ctrl+R all the statements to replay the session so far Is there a way to speed up the loop, e.g. via loading packages directly from ghci or saving/replaying a session? Cheers, Simon

3 3

Created haskell-indexer-users mailing list
by Robin Palotai 19 Jan '18

19 Jan '18

Hello Cafe, I created https://groups.google.com/forum/#!forum/haskell-indexer-users, please join if you use / interested in using haskell-indexer [1]! Quoting Section 4.5.5 of the latest HCAR [2], > > Haskell Indexer is a Kythe extension for working with Haskell source code. > Kythe is language-agnostic ecosystem for building tools that work with > code. An example is code search with cross-reference support: > https://cs.chromium.org/. Haskell Indexer makes it possible to use > Kythe-based tools with Haskell. With Haskell Indexer it’s possible to list > all use-sites of any given function (get reverse-references) and explore > the code without any IDE setup. > A portion of GHC and Stackage is indexed and available at > http://stuff.codereview.me/. Thank you & happy coding, Robin [1] https://github.com/google/haskell-indexer [2] https://www.haskell.org/communities/11-2017/html/report.html

1 0

GHC option for performance related output files folder?
by PY 19 Jan '18

19 Jan '18

Hello, All. I made instrumental build which generates profiling information. Cabal's options are: ghc-options: -Wall -O2 -threaded -prof -fprof-auto -rtsopts -fprof-cafs "-with-rtsopts=-N -s -h -i0.1 -p -M1G -SMyApplication-S.log" so running application generates files: /MyApplication-S.log, MyApplication.hp, MyApplication.prof/ but in current working directory - which is the problem (also I need to run it on Windows and Linux). Is it possible to specify directory of those output files with some option? Without this I get "Can't open ... file..." due to permission error - Haskell Runtime tries to save all of them in current folder (on Linux and on Windows standard folders for binaries is not allowed for writing, sure). === Best regards, Paul

1 0

Http client: tlsManagerSettings
by PY 18 Jan '18

18 Jan '18

Hello List! I see that tlsManagerSettings eats > 55Mb. Is it normal? It happens when it reads certificates. So, if it's normal, is it possible that it will consume much-much more on other systems/environments? On what does it depend? === Best regards, Paul

1 0

Versioning of libraries bundled with GHC pre-releases
by Ben Gamari 17 Jan '18

17 Jan '18

TL;DR. We propose to start following the PVP for core libraries shipped with GHC alpha release. Let us know what you think. Hello everyone, GHC has recently been reworking its release policy, increasing the release cadence to two releases per year. We hope that this change facilitates earlier and more thorough testing of GHC. Of course, a compiler is worth little if no real-world packages can be built with it. Historically library maintainers have been reluctant to offer releases claiming compatibility with pre-release GHCs due to the lax versioning guarantees offered by such pre-releases. Specifically, changes to libraries shipped with GHC pre-releases have historically not had proper distinct version numbers, causing unnecessary breakage for released code (e.g. [1]). To make maintainers feel more at ease with releasing libraries compatible with GHC alpha releases, we propose to start using the Package Versioning Policy (PVP) [2] to version GHC's core libraries with each alpha release. That is, libraries which are not source-identical will get at very least a minor bump with each alpha release. By "core libraries" we mean the set of: * base * template-haskell * integer-gmp * integer-simple * hpc * ghci * ghc-compact * all GHC dependencies not maintained by GHC HQ * ghc-prim * ghc-boot * ghc-boot-th Following the PVP will allow maintainers to safely release libraries to Hackage without fear that they will break when the final GHC 8.4.1 release is made, easing the testing process for everyone. If you have an opinion one way or another on this matter please do share it on this list. Cheers, - Ben [1] https://github.com/tibbe/hashable/issues/143 [2] https://pvp.haskell.org/

3 3