July 2023 - Haskell-Cafe

Best way to implement "scoped exceptions"?
by Tom Ellis 27 May '25

27 May '25

I'd like to implement "scoped exceptions"[1], that is, a combinator of type withScopedException :: ((forall a. e -> IO a) -> IO r) -> IO (Either e r) so I can use exceptions in a convenient way, without having to set up fragile "action at a distance" based on the type of the thing I'm throwing and catching, for example: scopedExceptionExample :: IO (Either String (Either Int Void)) scopedExceptionExample = do withScopedException $ \throw1 -> withScopedException $ \throw2 -> if (1 :: Int) < 0 then throw1 "Hello" else throw2 1234 -- ghci> scopedExceptionExample -- Right (Left 1234) Here's a hacky way of doing it, based on tagging each exception with a unique value, and then filtering when handling: data MyException where MyException :: e -> Data.Unique.Unique -> MyException instance Show MyException where show _ = "<MyException>" instance Exception MyException withScopedException :: ((forall a. e -> IO a) -> IO r) -> IO (Either e r) wiathScopedException f = do fresh <- Data.Unique.newUnique flip tryJust (f (\e -> throwIO (MyException e fresh))) $ \case MyException e tag -> -- unsafeCoerce is very unpleasant if tag == fresh then Just (unsafeCoerce e) else Nothing This is the approach taken by the effectful library[2]. But is there a better way? Can I persuade GHC's RTS to work like this directly? Tom [1] I don't know if these already have a name [2] https://hackage.haskell.org/package/effectful-core-2.2.1.0/docs/src/Effectf…

5 7

Haskell GitLab abuse
by aeiouaeiouaeiouaeiouaeiouaeiou 03 Aug '23

03 Aug '23

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi everyone, I don't know where the best place to post about this issue is, so here goes. Recently I found that some Google results are bloated with malicious links from Haskell GitLab fork repositories. You can see for yourself: https://gitlab.haskell.org/search?repository_ref=master&scope=blobs&search=… [...] Content analysis details: (5.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 SINGLE_HEADER_3K A single header contains 3K-4K characters 1.3 HK_RANDOM_FROM From username looks random 0.0 HK_RANDOM_ENVFROM Envelope sender username looks random -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

3 2

IFL23 - Deadline extension - Symposium on Implementation and Application of Functional Languages
by Pieter Koopman 31 Jul '23

31 Jul '23

Dear all, on special request, the deadline for draft paper submissions is extended until *August 7th*, 2023. *Scope* The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2022 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: * language concepts * type systems, type checking, type inferencing * compilation techniques * staged compilation * run-time function specialization * run-time code generation * partial evaluation * abstract interpretation * metaprogramming * generic programming * automatic program generation * array processing * concurrent/parallel programming * concurrent/parallel program execution * embedded systems * web applications * embedded domain specific languages * security * novel memory management techniques * run-time profiling performance measurements * debugging and tracing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * industrial applications *Submissions and peer-review* Following IFL tradition, IFL 2023 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that accepted draft papers are presented physically at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. Contributions submitted for the draft paper deadline must be between two and twelve pages long. For submission details, please consult the IFL 2023 website at https://ifl23.github.io/ <https://ifl21-publicity-dot-yamm-track.appspot.com/2BAsSNEGa7Qjzm9dLvMbB3Fu…> . *Where* IFL 2023 will be held physically in Braga, Portugal, arranged by University of Minho. See the IFL 2023 website at https://ifl23.github.io/ <https://ifl21-publicity-dot-yamm-track.appspot.com/202BkMEM4iDsNER-G6iYruAX…> for more information. [image: beacon]

1 0

developing using .devcontainer in vscode
by Han Joosten 31 Jul '23

31 Jul '23

Hi Cafe, I am trying to set up a useful development container for an open source project I am working on. I have created an image on top of the official Haskell image, expecting a proper installation of ghcup, cabal, stack and hls. The Dockerfile looks like this: FROM haskell:8.10 ARG USERNAME=vscode ENV USERNAME=${USERNAME} \ USER_UID=1000 \ USER_GID=1000 \ DEBIAN_FRONTEND=noninteractive \ LANG=C.UTF8 \ WDIR=/home/${USERNAME} RUN apt-get update && \ apt-get upgrade -y && \ apt-get install -y git RUN groupadd --gid $USER_GID $USERNAME && \ useradd -ms /bin/bash -K MAIL_DIR=/dev/null --uid $USER_UID --gid $USER_GID -m $USERNAME && \ mkdir -p /etc/sudoers.d && \ echo $USERNAME ALL=$root$ NOPASSWD:ALL > /etc/sudoers.d/$USERNAME && \ chmod 0440 /etc/sudoers.d/$USERNAME USER ${USER_UID}:${USER_GID} WORKDIR ${WDIR} RUN stack update # Add just the .cabal file to capture dependencies COPY ./package.yaml ${WDIR}/package.yaml COPY ./stack.yaml ${WDIR}/stack.yaml # Docker will cache this command as a layer, freeing us up to # modify source code without re-installing dependencies # (unless one of the copied files changes!) RUN stack build --only-dependencies -j4 COPY . ${WDIR} ENV DEBIAN_FRONTEND=dialog ENTRYPOINT ["/bin/bash"] The above image is built and pushed to dockerhub. Then, in the vscode project, I have a .devcontainer directory with the following Dockerfile: FROM ampersandtarski/ampersand-devcontainer:latest ENV DEBIAN_FRONTEND=dialog ENTRYPOINT ["/bin/bash"] The idea is that all the building of the dependencies is already done in the first image. That takes a lot of time, so this is supposed to be a great timesaver (though the image itself is huge). However, when I open the project inside the container, I get the following error: [image: image.png] If I reload the window, I get the following errors: [image: image.png] Long story short, I am not sure how to use the official Haskell image for development in my project. I must be missing something. I have been trying lots of things, but without succes. I hope it is possible to have an image built on top of the official Haskell file that contains all prebuilt dependencies of my project. Are my expectations realistic? If so, what am I missing? Any help is much appreciated.

2 1

[ANNOUNCE] GHC 9.8.1-alpha1 is now available
by Ben Gamari 28 Jul '23

28 Jul '23

The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeApplications` language extension [type-binders], allowing types to be bound in type declarations. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the 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 compiling, ~ Ben [type-binders]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-d… [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-s… [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-u… [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-w… [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-d… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha1/docs/users_guide/9.8.1-notes… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

IFL23 last Call for papers
by Pieter Koopman 28 Jul '23

28 Jul '23

Important Dates Draft Paper Submission Deadline 31st July, 2023 Notification of Acceptance for Presentation 1st August, 2023 Early Registration Deadline 11th August, 2023 Late Registration Deadline 23rd August, 2023 IFL Symposium 29th - 31st August, 2023 Submission of Papers for Peer-Reviewed Proceedings 24th November, 2023 Notification of Acceptance 2nd February, 2024 Camera-ready Version 8th March, 2024 SCOPE AND TOPICS The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. You can find more information about the symposium on its oficial website <https://ifl21-publicity-dot-yamm-track.appspot.com/29dDA6XwvedbWv4fOQOENw2-…>. IFL 2023 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. See the call for papers in text format <https://ifl21-publicity-dot-yamm-track.appspot.com/22-oQB0FEIVsa3YDKL7S2hh9…> . Areas of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - abstract interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - embedded domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - industrial applications PAPER SUBMISSIONS Following IFL tradition, IFL 2023 will use a post-symposium review process to produce the formal proceedings. Before the symposium, authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that accepted draft papers are presented physically at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. As in previous years, we will try to have the papers that are accepted for the formal proceedings published in the International Conference Proceedings Series of the ACM Digital Library. This possibility will be confirmed as soon as possible. Reviewing is single blind. There will be at least 3 reviews per paper. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. Papers must use the ACM two columns conference format, which can be found here <https://ifl21-publicity-dot-yamm-track.appspot.com/2Z34AGflDaGf8EcFImELD02V…>. (For LaTeX users, start your document with \documentclass[sigconf,screen,review]{acmart}.) All contributions must be written in English. Note that this format has a rather long but limited list of packages that can be used. Please make sure that your document adheres to this list. The page limit for papers is twelve pages (excluding references). Only papers that were presented at the IFL 2023 Symposium will be considered for publication. See the webpage for paper submissions. LOCATION IFL 2023 will be held physically in Braga, Portugal. For more information, click here <https://ifl21-publicity-dot-yamm-track.appspot.com/2YpNKpbXPCivYXoXnLEVurcA…>. Registration information will be added as soon as possible. [image: beacon]

1 0

Call for Participation, Functional Software Architecture - FP in the Large
by Graham Hutton 26 Jul '23

26 Jul '23

====================================================================== *** FUNARCH 2023 -- CALL FOR PARTICIPATION *** The First ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 8th September 2023, Seattle, Washington, USA Co-located with ICFP 2023 https://www.functional-architecture.org/events/funarch-2023/ ====================================================================== BACKGROUND: The ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large aims to disseminate and enable the use of functional programming in the large and long-lived software projects. We specifically want: - To assemble a community interested in software architecture techniques and technologies specific to functional programming; - To identify, categorize, and document topics relevant to the field of functional software architecture; - To connect the functional programming community to the software architecture community to cross-pollinate between the two. We'd love for you to be part of this effort. Whatever your background, you're welcome at FUNARCH - to listen to talks, report on your experience, and interact with others that share our goals. See you at FUNARCH! REGISTRATION: You can register for the workshop via the registration page for the ICFP conference, but there's no need to also register for the conference. Reduced fees are available until 5th August. http://icfp23.sigplan.org/attending/registration OPENING TALK: Functional Programming in the Large - Status and Perspective Mike Sperber ACCEPTED SUBMISSIONS: A Software Architecture Based on Coarse-Grained Self-Adjusting Computations Stefan Wehr Crème de la Crem: Composable Representable Executable Machines Marco Perone and Georgios Karachalias Functional Shell and Reusable Components for Easy GUIs Ben Knoble and Bogdan Popa Phases in Software Architecture Jeremy Gibbons, Oisín Kidney, Tom Schrijvers and Nicolas Wu Stretching the Glasgow Haskell Compiler Jeffrey M. Young, Sylvain Henry and John Ericson Typed Design Patterns for the Functional Era Will Crichton Types that Change: The Extensible Type Design Pattern Ivan Perez PROGRAM CHAIRS: Mike Sperber Active Group, Germany Graham Hutton University of Nottingham, UK PROGRAM COMMITTEE: Joachim Breitner Germany Manuel Chakravarty Tweag & IOG, The Netherlands Ron Garcia University of British Columbia, Canada Debasish Ghosh LeadIQ, India Lars Hupel Giesecke+Devrient, Germany Andy Keep Meta, USA Shriram Krishnamurthi Brown University, USA Andres Löh Well-Typed, Germany Anil Madhavapeddy University of Cambridge, UK José Pedro Magalhães Standard Chartered, UK Simon Marlow Meta, UK Hannes Mehnert Robur, Germany Erik Meijer USA Ivan Perez KBR / NASA Ames Research Center, USA Stefanie Schirmer DuckDuckGo, Germany Perdita Stevens University of Edinburgh, UK Stefan Wehr Hochschule Offenburg, Germany Scott Wlaschin FPbridge, UK WORKSHOP VENUE: The workshop will be co-located with the ICFP 2023 conference at The Westin Seattle Hotel, Seattle, Washington, United States. ====================================================================== 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

Munich Haskell Meeting, 2023-07-26 @ 19:30
by Leah Neukirchen 24 Jul '23

24 Jul '23

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, July 26 at Cafe Puck at 19h30, as the weather will be wet and cold. 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 nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/QEVV6sKxTm2DGwle Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Redundant/overlapping patterns?
by Todd Wilson 22 Jul '23

22 Jul '23

Hi, Cafe, Can someone please explain this: ghci> case 1 of 2 -> 3 <interactive>:1:11: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... *** Exception: <interactive>:1:1-16: Non-exhaustive patterns in case The non-exhaustive patterns part is obvious, but what is redundant about this match? And how can there be overlapping patterns when there's only one? Todd Wilson

6 10

Citation information for 'base' hackage docs
by Patrick L Redmond 18 Jul '23

18 Jul '23

Hi Haskell-Cafe, I'd like to cite the documentation for a particular module and version of the "base" package in an academic publication. In this case, it makes sense to cite the documentation instead of the papers listed at the top because the behavior described in the documentation isn't described by the papers (the module's implementation has diverged from them). To what author should I attribute the documentation? The page lists " libraries(a)haskell.org" as the maintainer. What title should I give for the work? The html title is "Control.Exception". Thank you, Patrick

3 2