- Haskell-Cafe - Haskell.org

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 25 Sep '18

25 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

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 20 Sep '18

20 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 20 Sep '18

20 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