May 2023 - Haskell-Cafe

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

28 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

type error when specializing lens zooms in ghc >= 9.0
by Olaf Klinke 02 Jun '23

02 Jun '23

Dear Cafe, I'm an infrequent lens user so please forgive me if the below problem has a trivial solution. For a long time the documentation of Control.Lens.Zoom has been claiming that 'zoom' and 'magnify' can be specialized to the following types. {-# LANGUAGE RankNTypes #-} -- Type error with GHC 9.0.2 or 9.2.7, okay with GHC 8.8.4 import Control.Lens.Zoom (zoom,magnify) import Control.Lens.Type (Lens') import Control.Monad.RWS (RWS) zoomRWS :: Monoid w => Lens' s s' -> RWS r w s' a -> RWS r w s a zoomRWS = zoom magnifyRWS :: Monoid w => Lens' r r' -> RWS r' w s a -> RWS r w s a magnifyRWS = magnify Indeed GHC 8.8.4 compiles this happily (on lens-4.18.1), but 9.0.2 (on lens-5.0.1) throws nearly undecipherable errors, claiming that Lens' can not be matched with some more specialized type involving Magnified and LensLike. The source of Control.Lens.Zoom does not differ substantially between 4.18.1 and 5.0.1 so my guess is it is a type checker issue. Can anyone explain? On which bug tracker should I raise this issue, if it is indeed a valid one? (I pulled the above versions from stackage lts-16.31, -19.5 and -20.20, respectively and compiled with stack.) Thanks Olaf

4 6

property testing, point-free style
by Olaf Klinke 01 Jun '23

01 Jun '23

Dear Cafe, The expression \x -> f x == g x is a testable property, as long as values for x can be randomly generated. For clarity I'd prefer a point-free style, e.g. f ≡ g Are there extensions to QuickCheck that let me write this? The QuickCheck package itself does not seem to contain such an operator. My current work-around is a newtype ExtensionalEquality a b that holds two functions of type (a -> b) and a Testable instance for it. But I've got a hunch that I re-invented some wheel here. (My ExtensionalEquality is isomorphic to Refl (a -> b) (a -> b) but Refl ist conceptually about type equality, not term equality.) Thanks Olaf

3 3

Call for Papers: JFP Special Issue on Program Calculation
by Graham Hutton 30 May '23

30 May '23

Dear all, We're delighted to announce a Special Issue on Program Calculation for the Journal of Functional Programming. Please share, and submit your best papers! Best wishes, Graham Hutton and Nicolas Wu Guest Editors ================================================================== JFP Special Issue on Program Calculation We invite submissions to the Journal of Functional Programming Special Issue on Program Calculation: tinyurl.com/prog-calc Notification of intent : 20 October 2023 Submission deadline : 1 December 2023 SCOPE The idea of program calculation, in which programs are derived from specifications using equational reasoning techniques, has been a topic of interest in functional programming since its earliest days. In particular, the approach allows us to systematically discover how programs can be defined, while at the same time obtaining proofs that they are correct. The aim of this special issue is to document advances that have been made in the field of program calculation in recent years. TOPICS Full-length, archival-quality submissions are solicited on all aspects of program calculation and related topics. Specific topics of interest include but are not limited to: - Program derivation and transformation; - Inductive and co-inductive methods; - Recursion and co-recursion schemes; - Categorical and graphical methods; - Tool support and proof assistants; - Efficiency and resource usage; - Functional algorithm design; - Calculation case studies. The special issue will also consider papers on program calculation that are not traditional research papers. This may include pearls, surveys, tutorials or educational papers, which will be judged by the usual JFP standards for such submissions. Papers will be reviewed as regular JFP submissions, and acceptance in the special issue will be based on both JFP's quality standards and relevance to the theme. NOTIFICATION OF INTENT Authors must notify the special issue editors of their intent to submit by 20 October 2023. The notification of intent should be submitted by filling out the following form, which asks for data to help identify suitable reviewers: tinyurl.com/intent-to-submit If you miss the notification of intent deadline, but still wish to submit, please contact the special-issue editors. SUBMISSIONS Papers must be submitted by 1 December 2023. Submissions should be typeset in LaTeX using the JFP style file, and submitted through the JFP Manuscript Central system. Choose "Program Calculation" as the paper type, so it gets assigned to the special issue. Further author instructions are available from: tinyurl.com/JFP-instructions We welcome extended versions of conference or workshop papers. Such submissions must clearly describe the relationship with the initial publication, and must differ sufficiently that the author can assign copyright to Cambridge University Press. Prospective authors are welcome to discuss submissions with the editors to ensure compliance. SPECIAL-ISSUE EDITORS Graham Hutton <graham.hutton(a)nottingham.ac.uk> Nicolas Wu <n.wu(a)imperial.ac.uk> IMPORTANT DATES We anticipate the following schedule: 20 October 2023 : Notification-of-intent deadline 1 December 2023 : Submission deadline 22 March 2024 : First round of reviews 12 July 2024 : Revision deadline 4 October 2024 : Second round of reviews, if applicable 29 November 2024 : Final versions due ================================================================== 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

regex problem with ghc-8.6 and older
by Ben Franksen 29 May '23

29 May '23

Hi Everyone I was trying to fix a bug in a large program (darcs) and stumbled over a problem that I cooked down to the minimal test program below. The issue here is that with ghc-8.6 and earlier, properly handling an invalid regular expression (here: the empty string) does not work: somehow something calls "error". With ghc-8.8 and later it works as expected. In both cases the latest releases of the regex packages are used. {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Prelude hiding (fail) import Control.Monad.Fail import Control.Exception import Text.Regex.Base import Text.Regex.TDFA newtype RegexFail a = RegexFail { runRegexFail :: Either String a } deriving (Functor, Applicative, Monad) instance MonadFail RegexFail where fail = RegexFail . Left test :: RegexFail Regex test = makeRegexM "" main = handle (\(ErrorCall _) -> putStrLn "error call") $ case runRegexFail test of Left _ -> putStrLn "clean error handling" Right x -> print (matchM x "" :: Maybe Bool) > runghc-8.6 test2.hs √ error call > runghc-8.8 test2.hs √ clean error handling (1) Is this a known problem with ghc < 8.8 / base < 4.13? (2) Is there a work-around for older ghc versions? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

4 5

GHC handling of signals
by Ben Franksen 28 May '23

28 May '23

Consider the following program: import System.IO import System.IO.Error import System.Posix.Signals main = do installHandler sigPIPE Default Nothing c <- readFile "/usr/share/dict/words" putStrLn c `catchIOError` \e -> hPutStrLn stderr (show e) hPutStrLn stderr "I survived" Compile with ghc and run as ./test | true As expected, you see nothing further displayed, since according to `man 7 signal` the default for SIGPIPE is to terminate the program, which happens before the exception handler has a chance to run. Without the line where the signal handler gets installed the behavior is different: You'll see: <stdout>: commitBuffer: resource vanished (Broken pipe) I survived Apparently the GHC runtime does something like installHandler sigPIPE Ignore Nothing This is not a complaint, I find the behavior quite reasonable and much more predictable than the default (why should I not be able to catch EPIPE and continue?). The question is whether it is documented how the GHC runtime treats signals and if yes where? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

3 3

Munich Haskell Meeting, 2023-05-29 @ 19:30
by Leah Neukirchen 28 May '23

28 May '23

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 29 at 19h30. The weather should be good, so we'll meet at **Hirschgarten Biergarten**. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can look out for you. It is OK to add yourself to the nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/xduCn5pUNTlcl7dT Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

3 2

Developer Surveys
by Dev Survey 27 May '23

27 May '23

Hello Developers, No login required, anonymous survey, and takes no more than 5-10 minutes. Developer Tools Survey Shortened URL : Developer Tools Survey (Anonymous) Thanks, have a great day

3 3

Searching for dependent code
by Geraldus 26 May '23

26 May '23

Hello, dear Cafe! I have a mono repository and would like to do the following for CI: - take the files from the commit - Find all the code that depends on them explicitly or implicitly - make a list of executable files that need to be rebuilt This happens in CI and there is no cache of previous builds. Note that dependencies may not be direct, e.g: - there are packages A, B, C. - C depends only on B - B depends on A - C should be rebuilt if there were changes in A Can you please tell me if there is any ready-made solution for this?

2 1

[Haskell] [ANNOUNCE] GHC 9.2.8 released
by Zubin Duggal 26 May '23

26 May '23

The GHC developers are happy to announce the availability of GHC 9.2.8. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.2.8). This release is primarily a bugfix release addressing one issue found in 9.2.7: - Fix a bug with RTS linker failing with 'internal error: m32_allocator_init: Failed to map' on newer Linux kernels (#19421). 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 compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.8/docs/html/users_guide/9.2.8-notes.…

1 0