- Haskell-Cafe - Haskell.org

Deprecation cycle for classes
by Tom Ellis 16 Jun '19

16 Jun '19

I am unsure how to change the name of a class in a library whilst providing a safe deprecation cycle for the users of the library. Suppose I have version 1 of my library with a class -- Version 1 class Foo a where foo :: a and I want to migrate it to version 3 as follows, but with a deprecation cycle provided by version 2 that allows code to work with either version 1 and 2, or 2 and 3. -- Version 3 class Bar a where bar :: a Then I can try to write version 2 as -- Version 2 {-# ConstraintKinds #-} class Foo a where bar :: a bar = foo foo :: a foo = bar type Bar = Foo This satisfies the following conditions: Users of versions 1 and 2 can use * The constraint Foo * The method foo * The class Foo and method foo for implementing their own instances User of versions 2 and 3 can use * The constraint Bar * The method bar * The method bar for implementing their own instances but they cannot jointly use * The *class* Bar for implementing their own instances (since Bar is not a class, just a Constraint) Is there any way I can write a version 2 that allows users to implement instances that work with both version 2 and version 3? Thanks, Tom

3 5

Posting Request
by Michelle Keppler 13 Jun '19

13 Jun '19

Hello, Could you please post the following to the Haskell Cafe email? Galois is hiring for a variety of roles <https://news.us10.list-manage.com/track/click?u=49a6a2e17b12be2c5c4dcb232&i…> Including but not limited to: Software Engineers/Researchers, Project Managers, Hardware Engineers, and a Software Integration Engineer. We collaborate with organizations like NASA, DARPA, and AWS to explore blue sky ideas and turn them into usable technology. Some of the things we’ve worked on in the past: Formal methods, static analysis, cryptographic algorithms, abstract interpretation, type theory, formal verification, reinforcement learning, autonomous systems assurance, communication security, cyber-deception for network defense, DDoS defense, provable hardware security, and statistical anomaly detection for detecting advanced persistent threats. We think working here is awesome; see lifeatgalois.com <https://news.us10.list-manage.com/track/click?u=49a6a2e17b12be2c5c4dcb232&i…> . Thank you, Michelle Keppler -- Michelle Keppler Human Resources Partner michelle(a)galois.com <michelle(a)galois.com> 571-510-0659 *I* *galois* *I * *GALOIS, INC.* 901 N Stuart Street *I* Suite 501 *I* Arlington, VA 22203 www.galois.com

1 0

ANN: stack-2.1.1 release
by Emanuel Borsboom 13 Jun '19

13 Jun '19

Announcing the first release in the stack-2.1 series! You can download bindists for all supported platforms from https://github.com/commercialhaskell/stack/releases/tag/v2.1.1 The Stack 2 release represents a series of significant changes to how Stack works internally. For the vast majority of cases, these changes are backwards compatible, in that existing projects will continue to build in the same way with Stack 2 as they did with Stack 1. The large version bump is due to the fundamental internal changes to cache handling, database storage (using SQLite in place of binary files), implicit snapshots (which greatly improve the precompiled cache), and moving to Pantry. We have also removed some less used features, as listed in the release notes below. **Changes since v1.9.3** Major changes: * Switch over to pantry for managing packages. This is a major change to Stack's internals, and affects user-visible behavior in a few places. Some highlights: * Drop support for multiple package indices and legacy `00-index.tar` style indices. See [#4137](https://github.com/commercialhaskell/stack/issues/4137). * Support for archives and repos in the `packages` section has been removed. Instead, you must use `extra-deps` for such dependencies. `packages` now only supports local filepaths. * Add support for Git repositories containing (recursive) submodules. * Addition of new configuration options for specifying a "pantry tree" key, which provides more reproducibility around builds, and (in the future) will be used for more efficient package content downloads. You can also specify package name and version for more efficient config parsing. * __NOTE__ The new `stack freeze` command provides support for automatically generating this additional information. * Package contents and metadata are stored in an SQLite database in place of files on the filesystem. The `pantry` library can be used for interacting with these contents. * Internally, Stack has changed many datatypes, including moving to Cabal's definition of many data types. As a result of such changes, existing cache files will in general be invalidated, resulting in Stack needing to rebuild many previously cached builds in the new version. Sorry :(. * A new command, `stack freeze` has been added which outputs project and snapshot definitions with dependencies pinned to their exact versions. * The `ignore-revision-mismatch` setting is no longer needed, and has been removed. * Overriding GHC boot packages results in any other GHC boot packages depending on it being no longer available as a dependency, such packages need to be added explicitly when needed. See [#4510] (https://github.com/commercialhaskell/stack/issues/4510) * Cabal solver integration was not updated to support newer `cabal-install` versions so `stack solver` command was removed as well as a related option `--solver` from `stack new` and `stack init`. * Upgrade to Cabal 2.4 * Note that, in this process, the behavior of file globbing has been modified to match that of Cabal. In particular, this means that for Cabal spec versions less than 2.4, `*.txt` will match `foo.txt`, but not `foo.2.txt`. * Remove the `stack image` command. With the advent of Docker multistage builds, this functionality is no longer useful. For an example, please see [Building Haskell Apps with Docker](https://www.fpcomplete.com/blog/2017/12/building-haskell-apps-with-…. * Support building GHC from source (experimental) * Stack now supports building and installing GHC from source. The built GHC is uniquely identified by a commit id and an Hadrian "flavour" (Hadrian is the newer GHC build system), hence `compiler` can be set to use a GHC built from source with `ghc-git-COMMIT-FLAVOUR` * `stack.yaml` now supports a `configure-options`, which are passed directly to the `configure` step in the Cabal build process. See [#1438](https://github.com/commercialhaskell/stack/issues/1438) * Remove support for building GHCJS itself. Future releases of Stack may remove GHCJS support entirely. * Support for lock files for pinning exact project dependency versions Behavior changes: * `stack.yaml` now supports `snapshot`: a synonym for `resolver`. See [#4256](https://github.com/commercialhaskell/stack/issues/4256) * `stack script` now passes `-i -idir` in to the `ghc` invocation. This makes it so that the script can import local modules, and fixes an issue where `.hs` files in the current directory could affect interpretation of the script. See [#4538](https://github.com/commercialhaskell/stack/pull/4538) * When using `stack script`, custom snapshot files will be resolved relative to the directory containing the script. * Remove the deprecated `--upgrade-cabal` flag to `stack setup`. * Support the `drop-packages` field in `stack.yaml` * Remove the GPG signing code during uploads. The GPG signatures have never been used yet, and there are no plans to implement signature verification. * Remove the `--plain` option for the `exec` family of commands * Always use the `--exact-configuration` Cabal configuration option when building (should mostly be a non-user-visible enhancement). * No longer supports Cabal versions older than `1.19.2`. This means projects using snapshots earlier than `lts-3.0` or `nightly-2015-05-05` will no longer build. * Remove the `stack docker cleanup` command. Docker itself now has [`docker image prune`](https://docs.docker.com/engine/reference/commandline/image_prune/) and [`docker container prune`](https://docs.docker.com/engine/reference/commandline/container_prun…, which you can use instead. * Interleaved output is now turned on by default, see [#4702](https://github.com/commercialhaskell/stack/issues/4702). In addition, the `packagename> ` prefix is no longer included in interelaved mode when only building a single target. * The `-fhide-source-paths` GHC option is now enabled by default and can be disabled via the `hide-source-paths` configuration option in `stack.yaml`. See [#3784](https://github.com/commercialhaskell/stack/issues/3784) * Stack will reconfigure a package if you modify your `PATH` environment variable. See [#3138](https://github.com/commercialhaskell/stack/issues/3138). * For GHC 8.4 and later, disable the "shadowed dependencies" workaround. This means that Stack will no longer have to force reconfigures as often. See [#3554](https://github.com/commercialhaskell/stack/issues/3554). * When building a package, Stack takes a lock on the dist directory in use to avoid multiple runs of Stack from trampling each others' files. See [#2730](https://github.com/commercialhaskell/stack/issues/2730). * Stack will check occassionally if there is a new version available and prompt the user to upgrade. This will not incur any additional network traffic, as it will piggy-back on the existing Hackage index updates. You can set `recommend-stack-upgrade: false` to bypass this. See [#1681](https://github.com/commercialhaskell/stack/issues/1681). * `stack list-dependencies` has been removed in favour of `stack ls dependencies`. * The new default for `--docker-auto-pull` is enabled. See [#3332](https://github.com/commercialhaskell/stack/issues/3332). Other enhancements: * Support MX Linux in get-stack.sh. Fixes [#4769](https://github.com/commercialhaskell/stack/issues/4769). * Defer loading up of files for local packages. This allows us to get plan construction errors much faster, and avoid some unnecessary work when only building a subset of packages. This is especially useful for the curator use case. * Existing global option `--color=WHEN` is now also available as a non-project-specific yaml configuration parameter `color:`. * Adopt the standard proposed at http://no-color.org/, that color should not be added by default if the `NO_COLOR` environment variable is present. * New command `stack ls stack-colors` lists the styles and the associated 'ANSI' control character sequences that stack uses to color some of its output. See `stack ls stack-colors --help` for more information. * New global option `--stack-colors=STYLES`, also available as a non-project-specific yaml configuration parameter, allows a stack user to redefine the default styles that stack uses to color some of its output. See `stack --help` for more information. * British English spelling of 'color' (colour) accepted as an alias for `--color`, `--stack-colors`, `stack ls stack-colors` at the command line and for `color:` and `stack-colors:` in yaml configuration files. * New build option `--ddump-dir`. (See [#4225](https://github.com/commercialhaskell/stack/issues/4225)) * Stack parses and respects the `preferred-versions` information from Hackage for choosing latest version of a package in some cases, e.g. `stack unpack packagename`. * The components output in the `The main module to load is ambiguous` message now include package names so they can be more easily copy-pasted. * Git repos are shared across multiple projects. See [#3551](https://github.com/commercialhaskell/stack/issues/3551) * Use en_US.UTF-8 locale by default in pure Nix mode so programs won't crash because of Unicode in their output [#4095](https://github.com/commercialhaskell/stack/issues/4095) * Add `--tree` to `ls dependencies` to list dependencies as tree. [#4101](https://github.com/commercialhaskell/stack/issues/4101) * Add `--pedantic` to `ghci` to run with `-Wall` and `-Werror` [#4463](https://github.com/commercialhaskell/stack/issues/4463) * Add `--cabal-files` flag to `stack ide targets` command. * Add `--stdout` flag to all `stack ide` subcommands. * Use batches when unregistering packages with `ghc-pkg`. (See [#2662](https://github.com/commercialhaskell/stack/issues/2662)) * `get-stack` script now works on Windows CI machines of Appveyor, Travis and Azure Pipelines. See [#4535](https://github.com/commercialhaskell/stack/issues/4535)/ * Show snapshot being used when `stack ghci` is invoked outside of a project directory. See [#3651](https://github.com/commercialhaskell/stack/issues/3651) * The script interpreter now accepts a `--extra-dep` flag for adding packages not present in the snapshot. Currently, this only works with packages from Hackage, not Git repos or archives. * When using the script interpreter with `--optimize` or `--compile`, Stack will perform an optimization of checking whether a newer executable exists, making reruns significantly faster. There's a downside to this, however: if you have a multifile script, and change one of the dependency modules, Stack will not automatically detect and recompile. * `stack clean` will delete the entire `.stack-work/dist` directory, not just the relevant subdirectory for the current GHC version. See [#4480](https://github.com/commercialhaskell/stack/issues/4480). * Add `stack purge` as a shortcut for `stack clean --full`. See [#3863](https://github.com/commercialhaskell/stack/issues/3863). * Both `stack dot` and `stack ls dependencies` accept a `--global-hints` flag to bypass the need for an installed GHC. See [#4390](https://github.com/commercialhaskell/stack/issues/4390). * Add the `stack config env` command for getting shell script environment variables. See [#620](https://github.com/commercialhaskell/stack/issues/620). * Less verbose output from `stack setup` on Windows. See [#1212](https://github.com/commercialhaskell/stack/issues/1212). * Add an optional `ignore-expiry` flag to the `hackage-security` section of the `~/.stack/config.yaml`. It allows to disable timestamp expiration verification just like `cabal --ignore-expiry` does. The flag is not enabled by default so that the default functionality is not changed. * Include default values for most command line flags in the `--help` output. See [#893](https://github.com/commercialhaskell/stack/issues/893). * Set the `GHC_ENVIRONMENT` environment variable to specify dependency packages explicitly when running test. This is done to prevent ambiguous module name errors in `doctest` tests. * `get-stack` script now works on Windows CI machines of Appveyor, Travis and Azure Pipelines. See [#4535](https://github.com/commercialhaskell/stack/issues/4535) * Warn when a Docker image does not include a `PATH` environment variable. See [#2472](https://github.com/commercialhaskell/stack/issues/2742) * When using `system-ghc: true`, Stack will now find the appropriate GHC installation based on the version suffix, allowing you to more easily switch between various system-installed GHCs. See [#2433](https://github.com/commercialhaskell/stack/issues/2433). * `stack init` will now support create a `stack.yaml` file without any local packages. See [#2465](https://github.com/commercialhaskell/stack/issues/2465) * Store caches in SQLite database instead of files. * No longer use "global" Docker image database (`docker.db`). * User config files are respected for the script command. See [#3705](https://github.com/commercialhaskell/stack/issues/3705), [#3887](https://github.com/commercialhaskell/stack/issues/3887). * Set the `GHC_ENVIRONMENT` environment variable to `-` to tell GHC to ignore any such files when GHC is new enough (>= 8.4.4), otherwise simply unset the variable. This allows Stack to have control of package databases when running commands like `stack exec ghci`, even in the presence of implicit environment files created by `cabal new-build`. See [#4706](https://github.com/commercialhaskell/stack/issues/4706). * Use a database cache table to speed up discovery of installed GHCs * You can specify multiple `--test-arguments` options. See [#2226](https://github.com/commercialhaskell/stack/issues/2226) * Windows terminal width detection is now done. See [#3588](https://github.com/commercialhaskell/stack/issues/3588) * On Windows, informs users if the 'programs' path contains a space character and further warns users if that path does not have an alternative short ('8 dot 3') name, referencing the `local-programs-path` configuration option. See [#4726](https://github.com/commercialhaskell/stack/issues/4726) * Add `--docker-mount-mode` option to set the Docker volume mount mode for performance tuning on macOS. Bug fixes: * Ignore duplicate files for a single module when a Haskell module was generated from a preprocessor file. See [#4076](https://github.com/commercialhaskell/stack/issues/4076). * Only track down components in current directory if there are no hs-source-dirs found. This eliminates a number of false-positive warnings, similar to [#4076](https://github.com/commercialhaskell/stack/issues/4076). * Handle a change in GHC's hi-dump format around `addDependentFile`, which now includes a hash. See [yesodweb/yesod#1551](https://github.com/yesodweb/yesod/issues/1551) * Fix `subdirs` for git repos in `extra-deps` to match whole directory names. Also fixes for `subdirs: .`. See [#4292](https://github.com/commercialhaskell/stack/issues/4292) * Fix for git packages to update submodules to the correct state. See [#4314](https://github.com/commercialhaskell/stack/pull/4314) * Add `--cabal-files` flag to `stack ide targets` command. * Don't download ghc when using `stack clean`. * Support loading in GHCi definitions from symlinked C files. Without this patch, Stack will try to find object files in the directory pointed to by symlinks, while GCC will produce the object files in the original directory. See [#4402](https://github.com/commercialhaskell/stack/pull/4402) * Fix handling of GitHub and URL templates on Windows. See [commercialhaskell/stack#4394](https://github.com/commercialhaskell/stack/is… * Fix `--file-watch` not responding to file modifications when running inside docker on Mac. See [#4506](https://github.com/commercialhaskell/stack/issues/4506) * Using `--ghc-options` with `stack script --compile` now works. * Ensure the detailed-0.9 type tests work. See [#4453](https://github.com/commercialhaskell/stack/issues/4453). * Extra include and lib dirs are now order-dependent. See [#4527](https://github.com/commercialhaskell/stack/issues/4527). * Apply GHC options when building a `Setup.hs` file. See [#4526](https://github.com/commercialhaskell/stack/issues/4526). * Stack handles ABI changes in FreeBSD 12 by differentiating that version from previous. * Help text for the `templates` subcommand now reflects behaviour in stack 1.9 — that it downloads and shows a help file, rather than listing available templates. * Fix detection of aarch64 platform (this broke when we upgraded to a newer Cabal version). * Docker: fix detecting and pulling missing images with `--docker-auto-pull`, see [#4598](https://github.com/commercialhaskell/stack/issues/4598) * Hackage credentials are not world-readable. See [#2159](https://github.com/commercialhaskell/stack/issues/2159). * Warnings are dumped from logs even when color is enabled. See [#2997](https://github.com/commercialhaskell/stack/issues/2997) * `stack init` will now work for cabal files with sublibraries. See [#4408](https://github.com/commercialhaskell/stack/issues/4408) * When the Cabal spec version is newer than the global Cabal version, build against the snapshot's Cabal library. See [#4488](https://github.com/commercialhaskell/stack/issues/4488) * Docker: fix detection of expected subprocess failures. This fixes downloading a compatible `stack` executable when the host `stack` is not compatible with the Docker image (on Linux), and doesn't show an unnecessary extra error when the in-container re-exec'ed `stack` exits with failure. * The `stack ghci` command's `--ghc-options` flag now parses multiple options. See [#3315](https://github.com/commercialhaskell/stack/issues/3315). **Thanks to all our contributors for this release:** * Adam Bergmark * Akshay Mankar * Aleksey Kozin * ALeX Kazik * Alexey Kozin * Alexey Kuleshevich * Anders Kaseorg * Anders Kiel Hovgaard * Artyom Kazak * Bastian Krol * Björn Gohla * Brad Neimann * Brandon Chinn * Colin Woodbury * Cthulhu.Den * dadepo * Daniel Gröber * David Baynard * David Spies * David Vollbracht * dbaynard * Emanuel Borsboom * favonia * flip111 * Florjan Bartol * Gleb Popov * Hussein Ait-Lahcen * Isumi Feng * Janfel * Jurijs Oniscuks * Kayla Ngan * Kirill Zaborsky * Magicloud * Matt Audesse * Mauricio Fierro * Michael Sloan * Michael Snoyman * Mihai Maruseac * Mike Pilgrem * Neil Mitchell * NeonGraal * Niklas Hambüchen * penteract * Phil de Joux * Raghu Kaippully * Sibi * Sibi Prabakaran * Simon Hengel * skapazzo * Sylvain HENRY * Sylvain Henry * Taekyung * Timothy Clem * Tom Sydney Kerckhove * Valery V. Vorotyntsev * Vance Palacio * waddlaw * 欧阳泽

1 0

How to fix ambiguous type variable?
by Boris 13 Jun '19

13 Jun '19

Hi everyone, I was playing around with some tests and run into code that looks really similar to the following function someCheck :: (Show a, Read a, Eq a) => String -> a -> Bool someCheck s v = (read . show . read $ s) == v But obviously, it's not clear what instance to use in the right-most read and the show functions. So it doesn't compile. Out of curiosity, is it possible to make this function compile? I've struggled some time and could not find an answer by myself, so here I am. Thanks in advance! Cheers, boris(a)d12frosted.io

5 7

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 12 Jun '19

12 Jun '19

Dear Haskell community, the GHC Steering committee is seeking nominations for two or three new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until June 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Is there any place with nightly/master builds of GHC?
by Changlin Li 12 Jun '19

12 Jun '19

I'm interested in benchmarking GHC compile times (that is how long it takes GHC to compile a given file) on a more granular basis than official releases. It would be nice to save myself the hassle of re-building GHC across many different commits if there already was some archive of GHC builds (e.g. from master), even if it's a rolling archive over a short time window (e.g. per-week). Changlin

3 3

Final Call for Participation: Compose Conference [NYC, Jun 22- 23 2019]
by Gershom B 12 Jun '19

12 Jun '19

=============================================== Final Call for Participation Compose Conference 2019 Mon June 24 - Tue June 25 2019 (Unconference on Sat Jun 22 - Sun Jun 23) New York, NY Deadline for registration: June 14 at 11pm EST. http://www.composeconference.org/2019 =============================================== The practice and craft of functional programming :: Conference Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. Typed functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. It will feature a two days of great and wide-ranging talks * Invited Keynotes Donya Quick - Making Algorithmic Music David Spivak - Compositional Graphical Logic * Accepted Talks and Tutorials Kenny Foner - Functors of the World, Unite! Phillip Carter - The anatomy of the F# tools for Visual Studio Sebastien Mondet - Genspio: Generating Shell Phrases In OCaml Justin Le - Applicative Regular Expressions using the Free Alternative Gaetano Checinski - Buckaroo SAT - Solving a partially revealed SAT problem for Package Management Richard Feldman - From Rails to Elm and Haskell Samuel Gélineau - Stuck macros: deterministically interleaving macro-expansion and typechecking Vaibhav Sagar - Yes, IHaskell Can Do That! Fintan Halpenny - Bowl Full of Lentils Aditya Siram - A Tase Of ATS Ward Wheeler, Alex Washburn, Callan McGill - Phylogenetic Software in Haskell Igor Trindade Oliveira - Type Driven Secure Enclave Development using Idris David Christiansen - Bidirectional Type Checking Chris Smith - Teaching the intersection of mathematics and functional programming Brandon Kase - Fast Accumulation on Streams James Koppel - The Best Refactoring You’ve Never Heard Of Allister Beharry - Using Dependent Types in an F# DSL for Linear Algebra Diego Balseiro - Bridge Haskell and ReasonML in Production * Full abstracts: http://www.composeconference.org/2019/program * Conference Registration: https://www.eventbrite.com/e/new-york-compose-2019-tickets-56751182314 * Unconference Registration: https://www.eventbrite.com/e/new-york-compose-unconference-2019-tickets-603… * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at info(a)composeconference.org * Please forward this announcement to interested parties and lists.

1 0

creating dll fails: missing references
by Kees Bleijenberg 11 Jun '19

11 Jun '19

HI all, I try to create a dll with ghc (ver 8.6.5) on Windows 7 64 bits. I 'am using the dll with loadLibrary in a cpp program in Visual Studio. I create the dll with: ghc Vogels.hs ghc -c StartEnd.c ghc --make -static -shared -fPIC Vogels.o StartEnd.o -o Vogels.dll StartEnd.o defines HsStart and HsEnd to initialize and close the Haskell runtime. This works. I can create the dll and use the dll in VS. But, if I replace in Vogels.hs the line b=True with b <- doesFileExist vogelsFn, creating the dll fails with error message: Vogels.o:fake:(.text+0x35c): undefined reference to `directoryzm1zi3zi3zi2zmB9tglvOQ6L9Cf7zzVEJ1S6t_SystemziDirectory_doesFileEx ist_closure' Vogels.o:fake:(.text+0x37d): undefined reference to `directoryzm1zi3zi3zi2zmB9tglvOQ6L9Cf7zzVEJ1S6t_SystemziDirectory_doesFileEx ist_closure' Vogels.o:fake:(.data+0xd0): undefined reference to `directoryzm1zi3zi3zi2zmB9tglvOQ6L9Cf7zzVEJ1S6t_SystemziDirectory_doesFileEx ist_closure' It looks like GHC can't find the Directory package. I've installed this package. What can I do about it and how can I find out the dependencies in a *.hs or *.o file? Almost all documentation about dll's is about Linux or about using dll's in Haskell. Kees {-# LANGUAGE BlockArguments #-} {-# LANGUAGE ForeignFunctionInterface #-} module Vogels ( loadVogels ) where import System.Directory import Foreign.Ptr import Foreign.Storable import Foreign.C.String loadVogels :: String -> IO (Either String String) loadVogels vogelsFn = do -- b <- doesFileExist vogelsFn let b=True if b then return $ Left $ "Can\'t find " ++ vogelsFn else do txt <- readFile vogelsFn return $ Right txt loadVogelsFFI :: Ptr Int -> CString -> IO CString loadVogelsFFI messageKind vogelsFnFFI = do vogelsFn <- peekCString vogelsFnFFI eitherRes <- loadVogels vogelsFn case eitherRes of Left errMsg -> do poke messageKind 1 newCString errMsg Right txt -> do poke messageKind 0 newCString txt foreign export ccall loadVogelsFFI :: Ptr Int -> CString -> IO CString --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus

2 1

Assistant/Associate Professorships in Nottingham
by Graham Hutton 10 Jun '19

10 Jun '19

Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make multiple new appointments at the Assistant or Associate Professor level: https://tinyurl.com/y4qfdqps https://tinyurl.com/y2uw6tsa Applications in the area of the Functional Programming (FP) lab are strongly encouraged! The FP lab is keen to receive applications from candidates with an excellent publication record (e.g. papers in leading venues such as LICS, POPL, ICFP, JFP, TOPLAS, etc) and the ability to secure external funding to support their research. Further information about the FP lab is available from: https://tinyurl.com/y2ekdkqa The deadline for applications is Monday 8th July 2019. The advert mentions some specific research areas, but the positions are open to applicants from any area of Computer Science. -- Graham Hutton and Thorsten Altenkirch This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Re: [Haskell-cafe] conduit/pipes/streaming and prompt cleanup - using a decorator
by Daniel Díaz 10 Jun '19

10 Jun '19

I tried to tackle this problem in my "streaming-bracketed" library http://hackage.haskell.org/package/streaming-bracketed, by using a "decorator" that wraps regular streams, as opposed to having a resource-aware base monad. When lifting take-like functions to the decorator, new deallocation actions are inserted. On Tue, Jun 4, 2019 at 2:53 PM <haskell-cafe-request(a)haskell.org> wrote: > I'm using the 'streaming' library and realized it doesn't close files in a > timely way for the way I'm using it, and in fact can't, due to how the > library > works. I know conduit has put a lot of thought into closing resources in a > timely way, so I did an experiment to see what it does, but as far as I can > tell, conduit has the same problem. Maybe I'm doing it wrong? > > The situation is that I'm opening multiple files and mixing their output. > I want to close the inputs as soon as I'm done with them. But I can get > done with them earlier than the end of the file. Since all of these > libraries > are based on pulling from downstream, if you don't pull all the way to the > end, > the close at the end doesn't happen, and has to wait until runResourceT > returns, which is too late. I remember long ago reading Oleg's original > iteratee paper, and it seems like he called out this problem with > pull-based > iterators, that the iterator doesn't know when its caller is done with it, > so > it can't close files on time. > > Here's a conduit version that I think illustrates the situation: > > import qualified Conduit as C > import Conduit ((.|)) > import qualified Control.Monad.Trans as Trans > import qualified System.IO as IO > > main :: IO () > main = C.runResourceT $ C.runConduit pipe > > pipe :: C.ConduitM a c (C.ResourceT IO) () > pipe = fileLines "TODO" .| (C.takeC 3 >> C.yield "***") > .| C.mapM_C (Trans.liftIO . putStrLn) > > fileLines :: C.MonadResource m => FilePath -> C.ConduitT i String m () > fileLines fname = C.bracketP (IO.openFile fname IO.ReadMode) close > handleLines > > handleLines :: Trans.MonadIO m => IO.Handle -> C.ConduitT i String m () > handleLines hdl = loop > where > loop = do > eof <- Trans.liftIO $ IO.hIsEOF hdl > if eof then return () else do > line <- Trans.liftIO $ IO.hGetLine hdl > C.yield line > loop > > close :: IO.Handle -> IO () > close hdl = IO.hClose hdl >> putStrLn "=== close" > > This prints the first three lines of TOOD, then ***, and then "=== close", > where the close should go before the ***s. > > As far as I can see, conduit can't do this any more than 'streaming' can, > because 'C.takeC' is just some awaits and yields, with no indication that > the final await is more special than any other await. > > I think what would be necessary to solve this is that combinators like > 'take' > have to be able to tell the stream to close, and that has to propagate > back up > to each producer that has registered a cleanup. Of course this renders the > stream invalid, so it's not safe to have any other references to the stream > around, but I guess streams are stateful in general so that's always true. > Maybe I could accumulate the finalizers in the stream data type and have > combinators like 'take' call it as soon as they've taken their last. What > I actually wound up doing was make a 'takeClose' that also takes a 'close' > action to run when its done with the stream. It's not exactly general but > I'm > not writing a library so I don't need general. > > Is there some kind of standard or built-in solution for this situation? > I know others have given a lot more thought to streaming than I have, > so surely this issue has come up. > > I know there is a lot of talk about "prompt finalisation" and streams vs. > pipes vs. conduit, and talk about brackets and whatnot, but despite reading > various documents (https://hackage.haskell.org/package/streaming-with, > > http://www.haskellforall.com/2013/01/pipes-safe-10-resource-management-and.… > , > etc.) I still don't really understand what they're talking about. > It seems like they're really about reliable cleanup when there are > exceptions, not really about prompt cleanup. Certainly pipes-safe doesn't > do > prompt cleanup, at least not the kind I'm talking about. > > >

2 1