September 2018 - Haskell-Cafe

What is the best way to search information on Haskell Cafe?
by Rodrigo Stevaux 09 Oct '18

09 Oct '18

I am new to mailing lists. Like really new.

10 10

[JOB] Haskell job opportunity at RELEX Solutions in Helsinki, Finland
by Mats Rauhala 02 Oct '18

02 Oct '18

Would you like to get paid for writing Haskell? And do you live in Europe, preferably in Helsinki, Finland? If yes, please read on. RELEX Solutions is Europe's fastest growing provider of integrated retail and supply chain planning solutions. We are looking for a few Haskell developers to join our small, but impactful group of Haskellers to develop our internal tools. In this position you will be exposed to various technologies, such as Haskell, Servant, Elm, GHCJS, Terraform, Ansible, Nix, RHEL/CentOS, AWS etc. Your own interests are influential in what your daily work will consist of. Your main responsiblities will be some mix of development, operations and support of and around our coordination system. Interested in applying? Follow the link: https://relex.recruiterbox.com/jobs/fk01gjr/ Full remote for this position is negotiable, but you should be able to be present at the Helsinki office at least for a couple of weeks, preferably longer. Details of your contract are largely negotiable. Please note that the available position will be filled as soon as suitable candidates are found, so don't wait too long ;). I'm also available for questions: - 'masser' at functionalprogramming slack - 'MasseR' at freenode - 'mats.rauhala(a)gmail.com' email or on this mailing list. -- Mats Rauhala

2 1

Status of Cloud Haskell
by Alejandro Serrano Mena 28 Sep '18

28 Sep '18

Dear Café, I was wondering what is the current status of Cloud Haskell. Their website only mentions things until 2016, but I see that the 'distributed-process' library is itself well-maintained. It Cloud Haskell still the way to go for distributed processes in Haskell? Regards, Alejandro

2 1

Where is "minimumsBy"?
by Tom Ellis 28 Sep '18

28 Sep '18

Data.List.minimumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a https://www.stackage.org/haddock/lts-12.1/base-4.11.1.0/Data-List.html#v:mi… but there are many cases where that's quite unhelpful. Actually what we want is more like minimumsBy :: ... => (a -> a -> Ordering) -> t a -> [a] There can be many distinct minimizers. For example when I want to get the collection of the youngest people from [(Age, Person)] I want minimumsBy (compare `on` fst) [(12, alice), (15, balaji), (12, cho)] to return [(12, alice), (12, cho)] Does "minimumsBy" exist somewhere reasonably standard? Hoogle doesn't throw up anything obvious https://www.stackage.org/lts-12.1/hoogle?q=%28a+-%3E+a+-%3E+Ordering%29+-%3… Thanks, Tom

8 11

Suppress re-exported module's docs ...
by aditya siram 27 Sep '18

27 Sep '18

Is there any way to have Haddock ignore a re-exported module without hiding it? eg. here all of `B`'s exports/docs show up in `A`'s Haddock page and I don't want to see them there: module A ( ... module B ) import B ...

2 1

Re: [Haskell-cafe] clonetype
by Oleg Grenrus 26 Sep '18

26 Sep '18

The problem is that "All instances" is hard to pin point. We have open world assumption, so instances can be added later (in the dependency tree). Should they be cloned too? And even of you restrict to "instances visible at clonetype definition", that's IMHO not a good idea either, as it's implicit and volatile set (editing imports changes may change the set). So use either tagged-trick/pattern or GND. Haskell's heavy type machinery exists so we can explicitly and exactly say what we need or want. Tagged/phantom-pattern and GND are different, they have different pros & cons. Having `clonetype-fits-all` seems non-trivial to me. Sent from my iPhone > On 24 Sep 2018, at 15.25, Harendra Kumar <harendra.kumar(a)gmail.com> wrote: > > That comes close, but Haskell having such a heavy type machinery to do all the esoteric type stuff in the world, but not allowing you to express such a simple day to day programming thing in a simpler manner is not very satisfying. > > -harendra > >> On Mon, 24 Sep 2018 at 16:16, Oleg Grenrus <oleg.grenrus(a)iki.fi> wrote: >> data MyStringTag >> type MyString = Tagged MyStringTag String >> >> Sent from my iPhone >> >>> On 24 Sep 2018, at 13.42, Harendra Kumar <harendra.kumar(a)gmail.com> wrote: >>> >>> Often, we need to create a newtype that is equivalent to a given type for safety reasons. Using type synonym is useless from type safety perspective. With newtype, we have to add a "deriving" clause to it for deriving the required instances, to make it practically useful. >>> >>> Does it make sense, and is it possible to have something like a "clonetype" that creates a new type and derives all the instances of the parent type as well? It will be quite helpful in creating equivalent newtype synonyms quickly. Almost always, I do not use a newtype where I should just because of the inconvenience of deriving the instances. Ideally, we should just be able to say something like: >>> >>> clonetype MyString = String >>> >>> and we are good to go. What is the shortest possible way to achieve this with currently available mechanisms, if any? >>> >>> -harendra >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post.

7 10

Re: [Haskell-cafe] Is it possible to change the environment (reader) in applicative style?
by Rodrigo Stevaux 24 Sep '18

24 Sep '18

Hi, I found a paper from the Greats exactly about desugaring monads into applicatives: The type of >>= allows the second computation (f b) to depend on the result a of the first, whereas <*> does not. This is the essence of the difference between Monad and Applicative; Monad allows dependencies on previous results, whereas Applicative does not. "Desugaring Haskell’s do-Notation into Applicative Operations" by marlow, SPJ, kmett and mokhov

1 0

clonetype
by Harendra Kumar 24 Sep '18

24 Sep '18

Often, we need to create a newtype that is equivalent to a given type for safety reasons. Using type synonym is useless from type safety perspective. With newtype, we have to add a "deriving" clause to it for deriving the required instances, to make it practically useful. Does it make sense, and is it possible to have something like a "clonetype" that creates a new type and derives all the instances of the parent type as well? It will be quite helpful in creating equivalent newtype synonyms quickly. Almost always, I do not use a newtype where I should just because of the inconvenience of deriving the instances. Ideally, we should just be able to say something like: clonetype MyString = String and we are good to go. What is the shortest possible way to achieve this with currently available mechanisms, if any? -harendra

3 2

ANN: stack-1.9 release candidate
by Emanuel Borsboom 24 Sep '18

24 Sep '18

This is the first release candidate for stack-1.9. Binaries for supported platforms are available here: https://github.com/commercialhaskell/stack/releases/tag/v1.9.0.1 ## Changes since v1.7.1 Release notes: * Statically linked Linux bindists are back again, thanks to [@nh2](https://github.com/nh2). **Please try the `stack-1.9.0.1-linux-x86_64-static.tar.gz` distribution if using Linux**, since it will be the default installed version once v1.9.1 is released. * We will be deleting the Ubuntu, Debian, CentOS, Fedora, and Arch package repos from `download.fpcomplete.com` soon. These have been deprecated for over a year and have not received new releases, but were left in place for compatibility with older scripts. Major changes: * `GHCJS` support is being downgraded to 'experimental'. A warning notifying the user of the experimental status of `GHCJS` will be displayed. Behavior changes: * `ghc-options` from `stack.yaml` are now appended to `ghc-options` from `config.yaml`, whereas before they would be replaced. * `stack build` will now announce when sublibraries of a package are being build, in the same way executables, tests, benchmarks and libraries are announced * `stack sdist` will now announce the destination of the generated tarball, regardless of whether or not it passed the sanity checks * The `--upgrade-cabal` option to `stack setup` has been deprecated. This feature no longer works with GHC 8.2 and later. Furthermore, the reason for this flag originally being implemented was drastically lessened once Stack started using the snapshot's `Cabal` library for custom setups. See: [#4070](https://github.com/commercialhaskell/stack/issues/4070). * With the new namespaced template feature, `stack templates` is no longer able to meaningfully display a list of all templates available. Instead, the command will download and display a [help file](https://github.com/commercialhaskell/stack-templates/blob/master/STAC… with more information on how to discover templates. See: [#4039](https://github.com/commercialhaskell/stack/issues/4039) * Build tools are now handled in a similar way to `cabal-install`. In particular, for legacy `build-tools` fields, we use a hard-coded list of build tools in place of looking up build tool packages in a tool map. This both brings Stack's behavior closer into line with `cabal-install`, avoids some bugs, and opens up some possible optimizations/laziness. See: [#4125](https://github.com/commercialhaskell/stack/issues/4125). * Mustache templating is not applied to large files (over 50kb) to avoid performance degredation. See: [#4133](https://github.com/commercialhaskell/stack/issues/4133). * `stack upload` signs the package by default, as documented. `--no-signature` turns the signing off. [#3739](https://github.com/commercialhaskell/stack/issues/3739) * In case there is a network connectivity issue while trying to download a template, stack will check whether that template had been downloaded before. In that case, the cached version will be used. See [#3850](https://github.com/commercialhaskell/stack/issues/3739). Other enhancements: * On Windows before Windows 10, --color=never is the default on terminals that can support ANSI color codes in output only by emulation * On Windows, recognise a 'mintty' (false) terminal as a terminal, by default * `stack build` issues a warning when `base` is explicitly listed in `extra-deps` of `stack.yaml` * `stack build` suggests trying another GHC version should the build plan end up requiring unattainable `base` version. * A new sub command `run` has been introduced to build and run a specified executable similar to `cabal run`. If no executable is provided as the first argument, it defaults to the first available executable in the project. * `stack build` missing dependency suggestions (on failure to construct a valid build plan because of missing deps) are now printed with their latest cabal file revision hash. See [#4068](https://github.com/commercialhaskell/stack/pull/4068). * Added new `--tar-dir` option to `stack sdist`, that allows to copy the resulting tarball to the specified directory. * Introduced the `--interleaved-output` command line option and `build.interleaved-output` config value which causes multiple concurrent builds to dump to stderr at the same time with a `packagename> ` prefix. See [#3225](https://github.com/commercialhaskell/stack/issues/3225). * The default retry strategy has changed to exponential backoff. This should help with [#3510](https://github.com/commercialhaskell/stack/issues/3510). * `stack new` now allows template names of the form `username/foo` to download from a user other than `commercialstack` on Github, and can be prefixed with the service `github:`, `gitlab:`, or `bitbucket:`. [#4039](https://github.com/commercialhaskell/stack/issues/4039) * Switch to `githash` to include some unmerged bugfixes in `gitrev` Suggestion to add `'allow-newer': true` now shows path to user config file where this flag should be put into [#3685](https://github.com/commercialhaskell/stack/issues/3685) * `stack ghci` now asks which main target to load before doing the build, rather than after * Bump to hpack 0.29.0 * With GHC 8.4 and later, Haddock is given the `--quickjump` flag. * It is possible to specify the Hackage base URL to upload packages to, instead of the default of `https://hackage.haskell.org/`, by using `hackage-base-url` configuration option. * When using Nix, if a specific minor version of GHC is not requested, the latest minor version in the given major branch will be used automatically. Bug fixes: * `stack ghci` now does not invalidate `.o` files on repeated runs, meaning any modules compiled with `-fobject-code` will be cached between ghci runs. See [#4038](https://github.com/commercialhaskell/stack/pull/4038). * `~/.stack/config.yaml` and `stack.yaml` terminating by newline * The previous released caused a regression where some `stderr` from the `ghc-pkg` command showed up in the terminal. This output is now silenced. * A regression in recompilation checking introduced in v1.7.1 has been fixed. See [#4001](https://github.com/commercialhaskell/stack/issues/4001) * `stack ghci` on a package with internal libraries was erroneously looking for a wrong package corresponding to the internal library and failing to load any module. This has been fixed now and changes to the code in the library and the sublibrary are properly tracked. See [#3926](https://github.com/commercialhaskell/stack/issues/3926). * For packages with internal libraries not depended upon, `stack build` used to fail the build process since the internal library was not built but it was tried to be registered. This is now fixed by always building internal libraries. See [#3996](https://github.com/commercialhaskell/stack/issues/3996). * `--no-nix` was not respected under NixOS * Fix a regression which might use a lot of RAM. See [#4027](https://github.com/commercialhaskell/stack/issues/4027). * Order of commandline arguments does not matter anymore. See [#3959](https://github.com/commercialhaskell/stack/issues/3959) * When prompting users about saving their Hackage credentials on upload, flush to stdout before waiting for the response so the prompt actually displays. Also fixes a similar issue with ghci target selection prompt. * If `cabal` is not on PATH, running `stack solver` now prompts the user to run `stack install cabal-install` * `stack build` now succeeds in building packages which contain sublibraries which are dependencies of executables, tests or benchmarks but not of the main library. See [#3787](https://github.com/commercialhaskell/stack/issues/3959). * Sublibraries are now properly considered for coverage reports when the test suite depends on the internal library. Before, stack was erroring when trying to generate the coverage report, see [#4105](https://github.com/commercialhaskell/stack/issues/4105). * Sublibraries are now added to the precompiled cache and recovered from there when the snapshot gets updated. Previously, updating the snapshot when there was a package with a sublibrary in the snapshot resulted in broken builds. This is now fixed, see [#4071](https://github.com/commercialhaskell/stack/issues/4071). * [#4114] Stack pretty prints error messages with proper `error` logging level instead of `warning` now. This also fixes self-executing scripts not piping plan construction errors from runhaskell to terminal (issue #3942). * Fix invalid "While building Setup.hs" when Cabal calls fail. See: [#3934](https://github.com/commercialhaskell/stack/issues/3934) * `stack upload` signs the package by default, as documented. `--no-signature` turns the signing off. [#3739](https://github.com/commercialhaskell/stack/issues/3739)

1 0

ANN: hslua-1.0.0
by Albert Krewinkel 24 Sep '18

24 Sep '18

HsLua provides bindings, wrappers, types, and helper functions to bridge Haskell and the embeddable scripting language Lua. The package ships with a Lua interpreter. HsLua allows to make Haskell programs extensible and scriptable via a widely used language. I am pleased to announce the release of hslua-1.0.0. Changes have been made to most parts of the library: Error handling became simpler, as conversion between Haskell exceptions and Lua errors is now automatic; other improvements concern type-safety, stability, and ease of use. Please see the changelog for the complete list of changes: <https://hackage.haskell.org/package/hslua/changelog> New versions of the extension packages hslua-aeson (marshalling via aeson) and hslua-module-text (a UTF-8 aware string module) have been released as well. For additional information and usage notes: <https://hslua.github.io> Best, - Albert

1 0