April 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

Call for Papers: Functional Software Architecture - FP in the Large
by Graham Hutton 10 May '23

10 May '23

Dear all, The first workshop on "Functional Software Architecture - FP in the Large” will be held in Seattle in Sept 2023, co-located with the ICFP conference. Please share, and submit your best papers, experience reports, and architectural pearls on large-scale functional programming! The submission deadline 1st June 2023. Best wishes, Mike Sperber and Graham Hutton Program Chairs, FUNARCH 2023 ====================================================================== *** FUNARCH 2023 -- CALL FOR PAPERS *** 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://tinyurl.com/FUNARCH-23 ====================================================================== TIMELINE: Paper submission 1st June 2023 Author notification 28th June 2023 Camera ready copy 18th July 2023 Workshop 8th Sept 2023 BACKGROUND: "Functional Software Architecture" refers to methods of construction and structure of large and long-lived software projects that are implemented in functional languages and released to real users, typically in industry. The goals for the workshop are: - 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. The workshop follows on from the Functional Software Architecture open space that was held at ICFP 2022 in Slovenia. SCOPE: The workshop seeks submissions in a range of categories: - You're a member of the FP community and have thought about how to support programming in the large, for example by framing functional ideas in architectural terms or vice verse, comparing different languages in terms of their architectural capabilities, clarifying architectural roles played by formal methods, proof assistants and DSLs, or observing how functional concepts are used in other language and architecture communities. Great, submit a research paper! - You're a member of the architecture community, and have thought about how your discipline might help functional programmers, for example by applying domain-driven design, implementing hexagonal architecture, or designing self-contained systems. Excellent, submit a research paper! - You've worked on a large project using functional programming, and it's worked out well, or terribly, or a mix of both; bonus points for deriving architectural principles from your experience. Wonderful, submit an experience report! - You know a neat architectural idiom or pattern that may be useful to others developing large functional software systems. Fabulous, submit an architectural pearl! - You have something that doesn't fit the above categories, but that still relates to functional software architecture, such as something that can be written up, or that could be part of the workshop format like a panel debate or a fishbowl. Superb, submit to the open category! Research papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and architectural pearls need not necessarily report original research results. The key criterion for such papers is that they make a contribution from which others can benefit. It is not enough simply to describe a large software system, or to present ideas that are specific to a particular system. Open category submissions that are not intended for publication are not required to follow the formatting guidelines, and can submit in PDF, word or plain text format as preferred. If you are unsure whether your contribution is suitable, or if you need any kind of help with your submission, please email the program chairs at <funarch2023(a)easychair.org>. SUBMISSION: Papers must be submitted by 1st June 2023 using EasyChair, via the following link: https://tinyurl.com/FUNARCH23-submit Formatting: submissions intended for publication must be in PDF format and follow the ACM SIGPLAN style guidelines, using the acmart format and the sigplan sub-format. Please use the review option, as this enables line numbers for easy reference in reviews. For further details, see: https://tinyurl.com/sigplan-acmart If your submission is not a research paper, please mark this using a subtitle (Experience Report, Architectural Pearl, Open Category). Length: submissions must adhere to the limits specified below. However, there is no requirement or expectation that all pages are used, and authors are encouraged to strive for brevity. Research papers 5 to 12+ pages Architectural pearls 5 to 12 pages Experience reports 3 to 6 pages Open category 1 to 6 pages Publication: The proceedings of FUNARCH 2023 will be published in the ACM Digital Library, and authors of accepted papers are required to agree to one of the standard ACM licensing options. Accepted papers must be presented at the workshop by one of the authors, but in special cases we may consider remote presentation. The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. 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 1

pretty-printing with fixed indentation increase per sub-structure
by Johannes Waldmann 04 May '23

04 May '23

Dear Cafe, I was looking for a way to pretty-print Haskell literals (with lists, tuples, records with named and positional notation) like this example ( Leftist { tree = Branch { left = Branch { left = Leaf, key = 4, right = Leaf } , key = 3 , right = Leaf } , refs = listToFM [ ( Ref 13, [ 0 ] ), ( Ref 17, [ ] ) ] } , [ Any, Any ] ) for each sub-structure, the indentation level (for the following lines) should increase - by a _fixed_ amount. in the above example: line break after "tree = Branch". But (missing from this example), line break _before_ the list starts in "{ foo = [ 42 , ... ] ... }". I found this impossible to do with wl-pprint but perhaps I did not try hard enough. Instead, I "invented" combinators `nest` and `skip` and made this prototypical implementation https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/blob/master/todoc/src/Te… (it has some explanatory text at the top) see also https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/issues/960 but certainly this cannot be a new idea. While I do like the semantics (in the context of my application), I don't like the performance of my implementation. What am I doing wrong? It's just updating indentation level and current position, this should not take any time at all? Of course, it would be best if I don't need the implementation at all - if the effect could be achieved via some combinators in established libraries (that have optimized implementation). Any pointers appreciated. Best regards - J.

4 4

"Hey! Monad! Leave my Pure alone!"
by Scott Michel 26 Apr '23

26 Apr '23

For a number of years, I've been hacking on a Z80 processor simulator, on and off. It's generally pure code that resembles and uses State, et. al. The design issue I've run into is adding devices to the memory system, unsurprisingly typed as MemorySystem. Devices like to do I/O, which potentially "pollutes" a design with Monads. So... I'm soliciting suggestions that allow me to isolate Monadic code in the middle of pure code (which might be Quixotic, but I'll accept that risk.) MemorySystem uses interval maps containing memory regions, and a memory region can be a RAMRegion, ROMRegion or DeviceRegion. The abbreviated data declarations are: type MemRegionMap addrType wordType = IM.IntervalMap addrType (MemoryRegion addrType wordType) data MemorySystem addrType wordType where MSys :: { _regions :: MemRegionMap addrType wordType } -> MemorySystem addrType wordType data MemoryRegion addrType wordType where EmptyRegion :: MemoryRegion addrType wordType RAMRegion :: {- ... -} ROMRegion :: {- ... -} DevRegion :: {- ... -} RAMRegion-s and ROMRegion-s are unboxed vector containers, which makes reading and writing to them pure State code, i.e., the last two function arguments to the reading function are "MemorySystem ... -> (Vector wordType, MemorySystem ...)", viz: type MemReadN addrType wordType = (Vector wordType, MemorySystem addrType wordType) mReadN :: addrType -- ^ Starting address -> Int -- ^ Number of words to read -> MemorySystem addrType wordType -- ^ The memory system from which to read -> MemReadN addrType wordType Supporting DevRegion-s gets more complicated, because I/O is involved (we like consoles on our machines, yes, we do.) I'd like to keep the reader signature without unnecessarily injecting a Monad or Monad Transformer into MemoryRegion and MemorySystem, thereby keeping the Monad or transformer isolated in DevRegion. For example, an internal device reader function would have a signature similar to "... -> Device m devType -> (Vector wordType, m devType)" instead of "... -> Device m devType -> m (Vector WordType, devType)", where "m" is the Monad or transformer. I know, it's hard to jailbreak things out of a Monad, which may be answering my own question. However, it seems to me that this kind of problem occurs in real world Haskell, and I haven't encountered the real world solution. Ideas? -scooter

2 1

Front page Haskell wiki site ( https://wiki.haskell.org/Haskell )
by Henk-Jan van Tuyl 25 Apr '23

25 Apr '23

L.S., The front page of the Haskell wiki site has changed, is a cascading style sheet missing? Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. https://foldingathome.org/ -- http://Van.Tuyl.eu https://HenkJanvanTuyl.werkaandemuur.nl/ https://sfeeraandemuur.nl/winkel/nekutimo/ https://github.com/HJvT https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourde… https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl… Haskell programming --

5 5

Munich Haskell Meeting, 2023-04-27 @ 19:30
by Leah Neukirchen 24 Apr '23

24 Apr '23

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

1 0

[ANN] dunai-0.11.0 and bearriver-0.14.2
by Ivan Perez 21 Apr '23

21 Apr '23

Dear all, I'm really excited to announce the release of Dunai 0.11.0 and Bearriver 0.14.2! Dunai is a reactive programming library structured around a notion of Monadic Stream Functions. Dunai can be used to implement other reactive and FRP frameworks on top, including Classic FRP and Arrowized FRP variants. Dunai comes with: - bearriver: API-compatible implementation of Yampa. (The Bear River is a tributary to the Yampa river.) - dunai-test: QuickCheck-based temporal testing library that can be connected with the testing system haskell-titan. See https://github.com/ivanperez-keera/dunai#features for details on Dunai's features. This release has addressed mainly styling issues. All library code now conforms to the main rules of the style guide we follow (which is publicly documented). We've also addressed other minor maintenance issues, like removal of unused code and updates to the README. In total, there have been more than 100 commits. Special thanks go to Miao ZhiCheng (@hellwolf on github) for a generous donation towards this release, and to Johannes Riecken (@johannes-riecken on github) for a regular contribution to support the dunai and Yampa projects. As always, dunai, dunai-test and bearriver are released in sync. For details, see: - https://github.com/ivanperez-keera/dunai/releases/tag/v0.11.0 *Releases* You can explore the current versions at: - https://hackage.haskell.org/package/dunai - https://hackage.haskell.org/package/dunai-test - https://hackage.haskell.org/package/bearriver *Code* The github repo is located at: https://github.com/ivanperez-keera/dunai *What's coming* This release comes exactly 2 months after the last release. The next release is planned for Jun 21, 2023. There are several issues open that you can contribute to: https://github.com/ivanperez-keera/dunai/issues Following our roadmap, the pending changes remain as follows: - Benchmarks: Facilitate making sound, evidence-based decisions about suggested improvements to the implementation, by completing a series of benchmarks. *Donations* Our project is now seeking donations to help continue developing dunai, create new open source libraries, new material, and give talks. Github will match the first 5K donated, so if you donate $1/month, github will donate the same amount. No donation is too small. Any contribution will absolutely help. See https://github.com/sponsors/ivanperez-keera for details. If you can help, please come forward. All the best, Ivan

1 0

3-year Research Associate or Research Assistant position in formal verification, using a proof assistant (preferably Isabelle), at the University of Sheffield
by Andrei Popescu 20 Apr '23

20 Apr '23

Dear colleagues, We have an opening for a 3-year position of either research associate or research assistant at the University of Sheffield, UK. It is on a project called "Safe and secure concurrent programming for advanced hardware architectures" and involves modelling and verification using a proof assistant, preferably Isabelle. Please share this opportunity with anyone you think might be interested. The closing date for applications is *** 23rd May 2023 *** More details can be found here: https://www.jobs.ac.uk/job/CYZ645/research-assistant-or-research-associate-… and here: https://jobs.shef.ac.uk/sap/bc/webdynpro/sap/hrrcf_a_posting_apply?PARAM=cG… Best wishes, Andrei Popescu https://www.andreipopescu.uk/

1 0

[Summer of Haskell 2023] Submit your proposal by tomorrow!
by Ida Bzowska 19 Apr '23

19 Apr '23

Hi Everyone, This is the last call to those wanting to participate in the Summer of Haskell program - project proposals are due by April 20, 2023 (tomorrow!). Details, including application instructions and a list of suggested projects and volunteer mentors, can be found at: summer.haskell.org Additionally, if your company or organization wants to support new open-source contributors, please email us at summer(a)haskell.org. Funding a stipend or two can have a significant positive impact on the Haskell ecosystem! Regards, Ida Bzowska

1 0

Re: [Haskell-cafe] Call for Papers: Functional Software
by Adrian Cochrane 18 Apr '23

18 Apr '23

Would you an experience report regarding building my own (no-JS) browserengine be appreciated? On Wed, Apr 19, 2023, at 12:00 AM, haskell-cafe-request(a)haskell.org wrote: > Dear all, > > The first workshop on "Functional Software Architecture - FP in the Large” > will be held in Seattle in Sept 2023, co-located with the ICFP conference. > > Please share, and submit your best papers, experience reports, and > architectural pearls on large-scale functional programming! > > The submission deadline 1st June 2023. > > Best wishes, > > Mike Sperber and Graham Hutton > Program Chairs, FUNARCH 2023 > > > ====================================================================== > > *** FUNARCH 2023 -- CALL FOR PAPERS *** > > 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://tinyurl.com/FUNARCH-23 > > ====================================================================== > > TIMELINE: > > Paper submission 1st June 2023 > Author notification 28th June 2023 > Camera ready copy 18th July 2023 > Workshop 8th Sept 2023 > > BACKGROUND: > > "Functional Software Architecture" refers to methods of construction > and structure of large and long-lived software projects that are > implemented in functional languages and released to real users, > typically in industry. The goals for the workshop are: > > - 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. > > The workshop follows on from the Functional Software Architecture > open space that was held at ICFP 2022 in Slovenia. > > SCOPE: > > The workshop seeks submissions in a range of categories: > > - You're a member of the FP community and have thought about how > to support programming in the large, for example by framing > functional ideas in architectural terms or vice verse, comparing > different languages in terms of their architectural capabilities, > clarifying architectural roles played by formal methods, proof > assistants and DSLs, or observing how functional concepts are > used in other language and architecture communities. > > Great, submit a research paper! > > - You're a member of the architecture community, and have thought > about how your discipline might help functional programmers, for > example by applying domain-driven design, implementing hexagonal > architecture, or designing self-contained systems. > > Excellent, submit a research paper! > > - You've worked on a large project using functional programming, > and it's worked out well, or terribly, or a mix of both; bonus > points for deriving architectural principles from your experience. > > Wonderful, submit an experience report! > > - You know a neat architectural idiom or pattern that may be useful > to others developing large functional software systems. > > Fabulous, submit an architectural pearl! > > - You have something that doesn't fit the above categories, but > that still relates to functional software architecture, such > as something that can be written up, or that could be part of > the workshop format like a panel debate or a fishbowl. > > Superb, submit to the open category! > > Research papers should explain their research contributions in both > general and technical terms, identifying what has been accomplished, > explaining why it is significant, and relating it to previous work, > and to other languages where appropriate. > > Experience reports and architectural pearls need not necessarily > report original research results. The key criterion for such papers > is that they make a contribution from which others can benefit. > It is not enough simply to describe a large software system, or > to present ideas that are specific to a particular system. > > Open category submissions that are not intended for publication > are not required to follow the formatting guidelines, and can > submit in PDF, word or plain text format as preferred. > > If you are unsure whether your contribution is suitable, or if > you need any kind of help with your submission, please email > the program chairs at <funarch2023(a)easychair.org>. > > SUBMISSION: > > Papers must be submitted by 1st June 2023 using EasyChair, via the > following link: https://tinyurl.com/FUNARCH23-submit > > Formatting: submissions intended for publication must be in PDF > format and follow the ACM SIGPLAN style guidelines, using the > acmart format and the sigplan sub-format. Please use the review > option, as this enables line numbers for easy reference in reviews. > For further details, see: https://tinyurl.com/sigplan-acmart > > If your submission is not a research paper, please mark this using > a subtitle (Experience Report, Architectural Pearl, Open Category). > > Length: submissions must adhere to the limits specified below. > However, there is no requirement or expectation that all pages > are used, and authors are encouraged to strive for brevity. > > Research papers 5 to 12+ pages > Architectural pearls 5 to 12 pages > Experience reports 3 to 6 pages > Open category 1 to 6 pages > > Publication: The proceedings of FUNARCH 2023 will be published in > the ACM Digital Library, and authors of accepted papers are required > to agree to one of the standard ACM licensing options. Accepted > papers must be presented at the workshop by one of the authors, but > in special cases we may consider remote presentation. > > The official publication date is the date the papers are made available > in the ACM Digital Library. This date may be up to two weeks prior to > the first day of the conference. The official publication date affects > the deadline for any patent filings related to published work. > > 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. > > > > >

2 1