May 2019 - Haskell-Cafe

ANN: stack-2.1 release candidate
by Emanuel Borsboom 26 May '19

26 May '19

Announcing the first release candidate of Stack 2.1! You can download bindists for Linux, macOS, and Windows from https://github.com/commercialhaskell/stack/releases/tag/v2.1.0.1. ### 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-docker) * 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_prune/) 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. * Document the way stack interacts with the Cabal library. * `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) 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/issues/4394) * 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).

1 0

Call For Papers: Workshop in OCL and Textual Modeling (OCL 2019)
by Achim D. Brucker 25 May '19

25 May '19

CALL FOR PAPERS 19th International Workshop on OCL and Textual Modeling Co-located with MODELS 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and System, September 15-20, 2019, Munich, Germany http://oclworkshop.github.io The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages (e.g., OCL, textual MOF, Epsilon, or Alloy) can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Submissions Four types of submissions will be considered: * Presentation only submission (not included in the workshop proceedings), e.g., for already published work. Authors should submit a short (1 page) abstract of their presentation. * Short papers (between 5 and 7 pages) describing new ideas or position papers. * Tool papers (between 5 and 7 pages) describing tools supporting textual modeling tools * Full papers (between 10 and 14 pages). All submissions should follow the LNCS format guidelines and should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2019). Accepted papers will be published online in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: 14 Jul 2019 - Notification: 25 Aug 2019 - Pre-Workshop CRC: 9 Sep 2019 - Post-Workshop CRC: 5 Oct 2019 -- Dr. Achim D. Brucker | Chair of Cybersecurity | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Munich Haskell Meeting, 2019-05-27 @ 19:30
by Leah Neukirchen 24 May '19

24 May '19

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 27 at Augustiner-Gaststätte Rumpler 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-may-2019/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leahneukirchen.org/

1 0

job opportunity at Luna
by Sylwia Brodacka 23 May '19

23 May '19

Luna (http://luna-lang.org) is an award-winning data-science platform and a general-purpose functional programming language, selected by NASA and Singularity University as 1 of the 20 most impressive technologies worldwide. It spans the entire stack, from high-level visualisation and communication, to the nitty-gritty of running backend services in a single language. With inbuilt capabilities for visualisation and a dual-syntax architecture, the possibilities are limitless. We are looking for talented and extraordinary people with strong technical skills and a passion for functional programming. Since majority of Luna codebase is written in Haskell we have available positions for senior Haskell developers for a variety of roles, including Compiler Engineer, DevOps Engineer, GUI Architect, and Cloud Software Engineer. If you want to learn more about possibilities please check out detailed job description: https://stackoverflow.com/jobs/264670/senior-haskell-developer-luna Cheers, Sylwia

1 0

Re: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) - clarification
by Pierre_van_der_Laar (Functional Account) 21 May '19

21 May '19

Dear All, The license issue can be summarized as follows: Whenever a program is compiled with GHC and is distributed on another platform than OS X, anybody can claim that the source code of that program must be provided due to the LGPL license, since integer-gmp, the ghc code, and that program's code are statically linked! Not convinced? Read e.g. https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes that discussed both the LGPL license and the usage of static libraries by GHC. For convenience, I have include the most relevant parts: ``` GMP is licensed under the GNU Lesser General Public License (LGPL), a kind of "copyleft" license. According to the terms of the LGPL, paragraph 5, you may distribute a program that is designed to be compiled and dynamically linked with the library under the terms of your choice (i.e., commercially) but if your program incorporates portions of the library, if it is linked statically, then your program is a "derivative"--a "work based on the library"--and according to paragraph 2, section c, you "must cause the whole of the work to be licensed" under the terms of the LGPL (including for free). The LGPL licensing for GMP is a problem for the overall licensing of binary programs compiled with GHC because most distributions (and builds) of GHC use static libraries. (Dynamic libraries are currently distributed only for OS X.) The LGPL licensing situation may be worse: even though The Glasgow Haskell Compiler License is essentially a "free software" license (BSD3), according to paragraph 2 of the LGPL, GHC must be distributed under the terms of the LGPL! ``` So the problem is real and seems to be underestimated by the Haskell user community based on the many (partly) incorrect responses on this mailing list. I still would like to know what GHC's strategy is to tackle this problem! Greetings, Pierre ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

3 2

[TFP'19 and TFPIE'19] call for participation
by Peter Achten 21 May '19

21 May '19

--------------------------------- C A L L F O R P A R T I C I P A T I O N --------------------------------- ====== TFP 2019 ====== 20th Symposium on Trends in Functional Programming 12-14 June, 2019 Vancouver, BC, CA https://www.tfp2019.org/index.html ====== TFPIE 2019 ====== 8th International Workshop on Trends in Functional Programming in Education 11 June, 2019 Vancouver, BC, CA http://www.staff.science.uu.nl/~hage0101/tfpie2019/index.html The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below at scope). Please be aware that TFP uses two distinct rounds of submissions (see below at submission details). TFP 2019 will be the main event of a pair of functional programming events. TFP 2019 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 11. == Invited Speakers == TFP 2019 is pleased to announce keynote talks by the following two invited speakers: Nikhil Swamy, Microsoft Research: Structuring the Verification of Imperative Programs with Functional Programming Frank Wood, University of British Columbia: Probabilistic Programming TFPIE 2019 is pleased to have the following invited speaker: Gregor Kiczales: Functional Programming at the Core of a High Throughput Software Engineering Curriculum == Scope == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: Leading-edge, previously unpublished research work Position Articles: On what new trends should or should not be Project Articles: Descriptions of recently started new projects Evaluation Articles: What lessons can be drawn from a finished project Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2019 program chairs, William J. Bowman and Ron Garcia. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Instructions to Author == Papers must be submitted at: https://easychair.org/conferences/?conf=tfp2019 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Papers submitted for post-symposium review (draft papers) will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == There are two types of submission, each of which can be submitted either for pre-symposium or post-symposium review: Extended abstracts. Extended abstracts are 4 to 10 pages in length. Full papers. Full papers are up to 20 pages in length. Each submission also belongs to a category: research position project evaluation overview paper Each submission should clearly indicate to which category it belongs. Additionally, a draft paper submission—of either type (extended abstract or full paper) and any category—can be considered a student paper. A student paper is one for which primary authors are research students and the majority of the work described was carried out by the students. The submission should indicate that it is a student paper. Student papers will receive additional feedback from the PC shortly after the symposium has taken place and before the post-symposium submission deadline. Feedback is only provided for accepted student papers, i.e., papers submitted for presentation and post-symposium formal review that are accepted for presentation. If a student paper is rejected for presentation, then it receives no further feedback and cannot be submitted for post-symposium review. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site (http://www.springer.com/lncs) == Program Committee == Program Co-chairs William J. Bowman University of British Columbia Ronald Garcia University of British Columbia Matteo Cimini University of Massachusetts Lowell Ryan Culpepper Czech Technical Institute Joshua Dunfield Queen's University Sam Lindley University of Edinburgh Assia Mahboubi INRIA Nantes Christine Rizkallah University of New South Wales Satnam Singh Google AI Marco T. Morazán Seton Hall University John Hughes Chalmers University and Quviq Nicolas Wu University of Bristol Tom Schrijvers KU Leuven Scott Smith Johns Hopkins University Stephanie Balzer Carnegie Mellon University Viktória Zsók Eötvös Loránd University

1 0

Re: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B)
by Pierre_van_der_Laar (Functional Account) 21 May '19

21 May '19

Dear Gershom / GHC development team, The provided windows version of GHC contains lib-gmp. Hence, this version enforces a LGPL license on my code (see e.g. https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes for more info) . Unfortunately, this license is unacceptable for me. For me this raises the question: What is the strategy of GHC with respect to licensing? In particularly, * Why considers GHC a LGPL license for all the code developed by their users acceptable? * Is GHC considering to allow their user to standardly develop their code under a license of their own choice? * Are there plans to offer the GHC users an opportunity to choose the license in the near future? e.g. by distributing GHC binary distributions with integer-gmp and integer-simple. Thanks in advance for your answers, Pierre van de Laar --------------------------------------------------------------------- Date: Wed, 8 May 2019 16:28:21 -0400 From: Gershom B <gershomb(a)gmail.com> To: haskell-cafe <haskell-cafe(a)haskell.org>, haskell(a)haskell.org Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 Message-ID: <CAM8RHpGB=mhYLJ_qDd__Td8vcJYBvZ66h0fErTU98H9DnWawmQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.6.5 Now available at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haske… This includes GHC 8.6.5, cabal-install 2.4.1.0, and stack 1.9.3. It is an incremental release over 8.6.3 intended mainly to make available bugfixes for windows in subsequent revisions in the 8.6 series and otherwise leave everything the same. These windows fixes are important, and it is recommended all windows users upgrade to 8.6.5 whether through the platform installer or some other mechanism. For detail on these changes and fixes see https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haske… https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haske… As with the 8.6.3 release, we are only providing core builds. Further, in 8.6.3 we moved from generic linux installers to recommending users install ghc through ghcup. As discussed in the last announcement, we have now moved to recommending os x users also use ghcup rather than a dedicated binary installer. For more details, please see the 8.6.3 announcement at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask… Happy Haskell Hacking all, Gershom ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

7 8

Second Call for Tutorial Proposals: ICFP 2019
by Sam Tobin-Hochstadt 20 May '19

20 May '19

*EXTENDED DEADLINE* - CALL FOR TUTORIAL PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Tutorials may occur after ICFP co-located with the associated workshops, from August 22 till August 23. ---------------------------------------------------------------------- Submission details Deadline for submission: June 3rd, 2019 Notification of acceptance: June 10th, 2019 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2018 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com by June 3rd, 2019. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by June 10th, 2019. The proposal form is available at: http://www.icfpconference.org/icfp2019-files/icfp19-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2019 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: François Pottier ( Inria, France) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com

1 0

How to dynamic plan in Haskell?
by Magicloud Magiclouds 20 May '19

20 May '19

Hi, I solved the question. But I could not figure out a FP style solution. Question: 1 - 9, nine numbers. Show all the possible combinations that sum up to 10. Different orders are counted as the same. For example, [1, 4, 5].

7 16

zstd package. Proposal to take over maintenance
by Luis Pedro Coelho 20 May '19

20 May '19

Hi everyone, The zstd package contains important bugs (it produces malformed output in some cases) and seems unmaintained. I would like to take over maintenance of it. I have actually forked the package and fixed the bugs, releasing it as hs-zstd: https://github.com/luispedro/hs-zstd http://hackage.haskell.org/package/hs-zstd I was advised to consider taking over maintenance of zstd as an earlier attempt to contact the maintainers of zstd was not answered. I would still prefer not to have this responsibility, but I would also like to use zstd in my work. * The zstd issues are not obvious because 99% of the time it works well, so we actually used it in a release of ngless, but after 3 days in the wild, we had to release a "bugfix". This is because most code paths work well, but there is one which produces a broken file. http://ngless.embl.de/whatsnew.html#version-0-11 Thanks, Luis Luis Pedro Coelho | Fudan University | http://luispedro.org https://orcid.org/0000-0002-9280-7885

1 0