- Haskell-Cafe - Haskell.org

Actual levity polymorphism
by Tom Ellis 11 Jan '23

11 Jan '23

I'm investigating unboxed types in GHC 9.2. Levity polymorphism seems to be severely limited in a way that makes it hard to envisage a Haskell ecosystem which comfortably combines lifted and unlifted types. Am I missing something? Understandably, the following attempt at defining a RuntimeRep-polymorphic identity does not work: myId1 :: forall (r :: RuntimeRep) (t :: TYPE r). t -> t myId1 x = x The GHC Users Guide explains why[1]. It's impossible to generate code for myId1 because there is no way of determining the machine representation of the argument x. But worse, it's not even possible to define a *Levity*-polymorphic identity: myId2 :: forall (lev :: Levity) (t :: TYPE (BoxedRep lev)). t -> t myId2 x = x In this case the argument can only have kind TYPE LiftedRep or TYPE UnliftedRep. The machine representation is the same in each case. The problem this time is that the code generator doesn't know whether it should emit code to evaluate the argument (UnliftedRep case) or not (LiftedRep case). But this seems like a solvable problem. Surely a KnownLevity type class (possibly magical) could solve the problem. This seems like it should work myId3 :: forall (lev :: Levity) (t :: TYPE (BoxedRep lev)). KnownLevity lev => t -> t myId3 x = x and in fact I wouldn't be surprised if this could be made to work: myId4 :: forall (r :: RuntimeRep) (t :: TYPE r). KnownRuntimeRep r => t -> t myId4 x = x So what is the situation here? 1. myId3 already works (then where is KnownLevity made available and why isn't it mentioned in the Users Guide?) 2. myId3 can never work (then why not?) 3. myId3 might be able to work but it's an open research problem (then who is working on it, if anyone?) 4. myId3 would work and it would be useful but no one's proposed or implemented it (then who would be the best person to collaborate with on that?) 5. myId3 would work but it would not actually be useful (then what have I misunderstood?) I suspect the answer is 1 (or maybe 4) based on the following passage in the Levity Polymorphism[2] paper by RE & SPJ[2]: > users can use a runtime type check (though GHC’s Typeable feature) > to determine the memory representation of an as-yet- unbound > argument to a function (and the same questions for myId4). Thanks, Tom [1] https://downloads.haskell.org/~ghc/9.4.4/docs/users_guide/exts/representati… [2] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/levity-…

5 8

[ANN] Copilot 3.13
by Ivan Perez 10 Jan '23

10 Jan '23

Dear all, I'm very excited to announce Copilot 3.13. Copilot is a stream-based DSL for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Among others, Copilot has been used at the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. It also serves as a runtime monitoring backend for the requirements elicitation tool FRET (https://github.com/NASA-SW-VnV/fret/) via Ogma ( https://github.com/nasa/ogma) This release fixes 4 bugs in copilot-core and copilot-c99. We have also removed 2 deprecated modules and one dependency. The new release has been published on hackage, as well as github. Current emphasis is on increasing test coverage, removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Users are encouraged to participate by opening issues and asking questions via our github repo ( https://github.com/copilot-language/copilot) I'd also like to take this opportunity to announce that Copilot is now being made available on Ubuntu Lunar 23.04 and Debian Bookworm. We would like to thank the Debian Haskell Group and, most especially, Scott Talbert, for continued effort making Copilot available on Debian-based distros. This will be extremely useful to a great portion of our users, who need to use Copilot as a runtime verification system targeting C, but do not need to become proficient in Haskell. We hope to continue this effort by making Copilot easily available on other distributions and OSs. Happy Haskelling, The Copilot team

1 0

HLS in VS Code is identifying problems that don't when I run stack on the command line
by Dennis Raddle 07 Jan '23

07 Jan '23

I'm trying to get HLS set up with a stack project on VS Code. I'm getting messages like this: Could not load module ‘Control.Monad.Except’ It is a member of the hidden package ‘mtl-2.2.2’. You can run ‘:set -package mtl’ to expose it. (Note: this unloads all the modules in the current scope.) But these are in the "Problems" tab of VS Code (and show as red underlines). When I run stack clean, stack build I don't see any error like this at all. And yes, I made sure mtl was added everywhere in cac.cabal. (I'm using cac.cabal not stack.yaml... is that my problem?) I tried stack clean; stack build; restart HLS several times.

2 4

Surprising behavior with wildcard pattern and unlifted type
by Tom Ellis 07 Jan '23

07 Jan '23

Is there supposed to be this surprising difference between ex1 and ex2? {-# LANGUAGE UnliftedDatatypes #-} {-# OPTIONS_GHC -Wall #-} module Main where import GHC.Exts (UnliftedType) type T :: UnliftedType data T = T ex1 :: () ex1 = let _ = undefined :: T in () ex2 :: () ex2 = let _a = undefined :: T in () ghci> ex1 () ghci> ex2 *** Exception: Prelude.undefined CallStack (from HasCallStack): undefined, called at test17.hs:53:16 in fake-package-0-inplace:Main

2 2

Surprising interaction between @-patterns and nested patterns
by Tom Ellis 05 Jan '23

05 Jan '23

Consider the following: let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () () but then combining the patterns into an @-pattern, which really feels like it shouldn't change semantics: let x1@((_, _), _) = (undefined, ()) in x1 `seq` () -> undefined Does this strike anyone else as odd? The reason for this behaviour is that let x@p = rhs in body is translated to case rhs of ~(x@p) -> body according to section 3.12 of The Report[1] which is then translated to (\x -> body) (case rhs of x@p -> x) if p binds no variables, according to section 3.17.3 of The Report[2], and then to (\x -> body) (case rhs of p -> (\x -> x) rhs) which is equivalent to (\x -> body) (case rhs of p -> rhs) Putting it all together let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () desugars as (\x0 -> x0 `seq` ()) (let v = (undefined, ()) in case v of ((_, _), _) -> v) which evaluates as let v = (undefined, ()) in case v of ((_, _), _) -> () This seems very odd to me. Why should combining two non-diverging patterns into an @-pattern cause divergence? Specifically, the translation from let x@p = rhs in body to case rhs of ~(x@p) -> body seems highly dubious. It comes from the more general rule translating let p = rhs in body to case rhs of ~p in body but it seems to interact badly with @-patterns. It seems like the rule for @-patterns should be something like let x@p = rhs in body translates to case rhs of ~(x@(~p)) in body Then the original expression containing x1 would not diverge. Does anyone else have a view on this matter? Tom [1] https://www.haskell.org/onlinereport/exps.html#sect3.12 [2] https://www.haskell.org/onlinereport/exps.html#sect3.17.3

4 5

CLC Election January 2023
by Andrew Lelechenko 04 Jan '23

04 Jan '23

The terms of three CLC members are ending in January, so we are seeking new nominations! # Who should apply? Anyone who meets the following criteria should apply: * Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (3 to 5 per month), and sustain this for their 3 years term in a healthy manner. * Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the CLC proposal process on a semi-frequent basis (3 to 5 per month). * Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. * Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room - quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. # How can I apply? To apply for one of these positions, send an email to clc.nominations.2023(a)gmail.com that consists of the following data: * The header “CLC Election January 2023 - {your name}”. * Why you think you’re a good fit given the above criteria. * If applicable, please point us to some code you’ve written. Please apply before Feb 1. Best regards, Andrew

1 0

[TFP 2023 Call For Participation] 24th International Symposium on Trends in Functional Programming
by Peter Achten 02 Jan '23

02 Jan '23

# TFP 2023 -- Call For Participation (trendsfp.github.io) ## Dates Registration: Friday 6th January, 2023 TFPIE Workshop: Thursday 12th January, 2023 TFP Symposium: Friday 13th - Sunday 15th January, 2023 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. This year, TFP will take place in-person at UMass Boston, Massachusetts in the United States. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. ## 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 2023 program chair, Stephen Chang. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, a prize for the best student paper is awarded each year. 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. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Papers must be submitted at: <https://easychair.org/conferences/?conf=tfp23> Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal 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 receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## 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. ## Program Committee Peter Achten, Radboud University Nijmegen, Netherlands Nada Amin, Harvard University, USA Ambrose Bonnaire-Sergeant, Untypable LLC, USA Laura M. Castro, University of A Coruña, Spain Stephen Chang (Chair), University of Massachusetts Boston, US John Clements, Cal Poly, USA Youyou Cong, Tokyo Institute of Technology, Japan Paul Downen, University of Massachusetts Lowell, USA Kathy Gray, Meta Platforms, Inc., UK Ben Greenman, University of Utah, USA Jason Hemann, Seton Hall University, USA Patricia Johann, Appalachian State University, USA Alexis King, Tweag, USA Julia Lawall, Inria-Paris, France Barak Pearlmutter, Maynooth University, Ireland Norman Ramsey, Tufts University, USA Ilya Sergey, National University of Singapore, Singapore Melinda Tóth, Eötvös Loránd University, Hungary Ningning Xie, University of Toronto, Canada

1 0

Special holiday Munich Haskell Meeting, 2023-01-04 @ 19:30
by Leah Neukirchen 30 Dec '22

30 Dec '22

Dear all, Next week, our special holiday Munich Haskell Meeting will take place on Wednesday, January 4 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 nuudel so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://nuudel.digitalcourage.de/cs8eLiDLkwZEd5hO Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

[Haskell] [ANNOUNCE] Haskell Language Server 1.9.0.0 released
by Zubin Duggal 26 Dec '22

26 Dec '22

Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-1.9.0.0/ The prebuilt binaries in this release support the following GHC versions: - 8.10.7 - 9.0.2 - 9.2.5 - 9.4.3 - 9.4.4 These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/) or version [2.0.0 and above](https://github.com/haskell/vscode-haskell/releases) of the VSCode extension. ## Changelog - Binaries for GHC 9.4.3, GHC 9.4.4 and GHC 9.2.5. - Dropped support for GHC 8.8 and GHC 8.10. - New plugins including: - Expanding record wild cards using hls-explicit-record-fields-plugin (#3304). - Formatting cabal fields using cabal-fmt via hls-cabal-fmt-plugin (#2047). - Warnings and errors for cabal files using hls-cabal-plugin (#2954). - Folding ranges using hls-code-range-plugin (#3058). - Support for many plugins like the refactor, splice, retrie, gadt, hlint, fourmolu and class plugins. - Completion for record dot fields (#3080). - Performance and memory usage improvements. - And many more bug fixes and improvements! For the full release notes, see https://github.com/haskell/haskell-language-server/releases/tag/1.9.0.0

1 1

[ANNOUNCE] GHC 9.4.4 is now available
by Ben Gamari 24 Dec '22

24 Dec '22

The GHC developers are happy to announce the availability of GHC 9.4.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org [1]. This release is primarily a bugfix release. Bugs fixed include: * An issue where the wrong labels were used in the eventlog for events emitted when using info table profiling which was broken in 9.4.3 (#22452) * Fix a long standing bug where invalid eventlogs would be produced with long command-lines (#20221) * Fix a regression in eta-expansion which resulted in serious performance regressions in 9.4.3 (#22424) * Fix the `-fdefer-diagnostics` flag (#22391) * Fixes to several subtle compiler panics (#22491, #22416, #22549, #22475, #22039) * Add necessary write barriers to `IORef` operations, avoiding potential soundness issues on architectures with weakly-ordered memory models (#22468) Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy Haskelling, - Ben [1]: https://downloads.haskell.org/ghc/9.4.4 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

2 3