- Haskell-Cafe - Haskell.org

[ANNOUNCE] GHC 9.2.2 is not available
by Ben Gamari 16 Mar '22

16 Mar '22

The GHC developers are very happy to at announce the availability of GHC 9.2.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.2.2 This release includes many bug-fixes and other improvements to 9.2.1 including: * A number of bug-fixes in the new AArch64 native code generator * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is handled correctly on platforms lacking support for unaligned memory accesses (#21015, #20987). * Improvements to the compatibility story in GHC's migration to the XDG Base Directory Specification (#20684, #20669, #20660) * Restored compatibility with Windows 7 * A new `-fcompact-unwind` flag, improving compatibility with C++ libraries on Apple Darwin (#11829) * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime bounds checking of array primops (#20769) * Unboxing of unlifted types (#20663) * Numerous improvements in compiler performance. * Many, many others. See the [release notes] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy compiling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.h…

3 3

JOB | Developers (Edinburgh)
by James Tobin 15 Mar '22

15 Mar '22

Hello, I'm working with a global fintech company looking to hire for their new office in Edinburgh. Should there be frontend or backend people that work with the likes of Core Java, Javascript, Typescript, React, RxJS interested in forming a small development squad do get in touch. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

1 0

bracket and type family
by PICCA Frederic-Emmanuel 14 Mar '22

14 Mar '22

Hello I try to have a generic way to open and close ressources for my software class DataResource a where data OpenedDataResource a :: * acquireDataResource :: a -> IO (OpenedDataResource a) releaseDataResource :: OpenedDataResource a -> IO () the idea is to have a generic method like this withDataResource :: DataResource a => a -> (OpenedDataResource a -> IO r) -> IO r withDataResource r = bracket (acquireDataResource r) releaseDataResource and later another one for the bracket of Pipes. So I try with something simple -- File newtype H5FilePath = H5FilePath FilePath instance DataResource H5FilePath where data OpenedDataResource H5FilePath = File acquireDataResource (H5FilePath f) = openFile (pack f) [ReadOnly] Nothing releaseDataResource = closeFile but I end up with this sort of error src/Hkl/H5.hs:231:40: error: • Couldn't match type ‘File’ with ‘OpenedDataResource H5FilePath’ Expected type: IO (OpenedDataResource H5FilePath) Actual type: IO File • In the expression: openFile (pack f) [ReadOnly] Nothing In an equation for ‘acquireDataResource’: acquireDataResource (H5FilePath f) = openFile (pack f) [ReadOnly] Nothing In the instance declaration for ‘DataResource H5FilePath’ | 231 | acquireDataResource (H5FilePath f) = openFile (pack f) [ReadOnly] Nothing | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ src/Hkl/H5.hs:232:25: error: • Couldn't match type ‘OpenedDataResource H5FilePath’ with ‘File’ Expected type: OpenedDataResource H5FilePath -> IO () Actual type: File -> IO () • In the expression: closeFile In an equation for ‘releaseDataResource’: releaseDataResource = closeFile In the instance declaration for ‘DataResource H5FilePath’ | 232 | releaseDataResource = closeFile | ^^^^^^^^^ cabal: Failed to build hkl-0.1.0.0 (which is required by exe:binoculars-ng from hkl-0.1.0.0). I do not understand why ? and more seriously, I do not know how to fix this. thanks for your help Frederic

2 1

Why is this package being compiled
by Henry Laxen 14 Mar '22

14 Mar '22

Dear Haskell friends, Is there a way to discover why a certain package is being compiled? In my case, the package cryptonite is a dependency of some other package, but I don't know which one. cryptonite doesn't compile on GHC 9.2.2, so if I can find out which package is causing it to be selected, perhaps I can work around my code so it (my code) does not depend on that package. I hope I am making myself clear. Any pointers would be appreciated. Best wishes, Nadine and Henry Laxen The rest is silence

4 4

Re: [Haskell-cafe] Retro/indie Haskell to appreciate
by Anthony Clayden 13 Mar '22

13 Mar '22

Hi Vanessa, in the same mould as 'Here documents' there's Hugs Extensible records /TRex https://www.haskell.org/hugs/pages/hugsman/exts.html#sect7.2 Not sure whether it counts as "retro": it still works, and is still superior to H2010 Datatype records (with GHC's extensions). AntC > I’m looking to appreciate “retro” Haskell projects, things from before stabilization/company use. > > Such as: > > > Hugs string extensions https://www.haskell.org/hugs/pages/users_guide/here-documents.html <https://www.haskell.org/hugs/pages/users_guide/here-documents.html>

1 0

[Call for participation] TFPiE and TFP online events March 16-18
by Peter Achten 13 Mar '22

13 Mar '22

------------------------------------------------------------------------------- C A L L F O R P A R T I C I P A T I O N 11th International Workshop on Trends in Functional Programming in Education + 23rd Symposium on Trends in Functional Programming 16 - 18 March 2022 wiki.tfpie.science.ru.nl/TFPIE2022 trendsfp.github.io ------------------------------------------------------------------------------- The programmes for TFPIE and TFP are online (all times are UTC+0): - TFPIE: https://wiki.tfpie.science.ru.nl/TFPIE2022 - TFP: https://trendsfp.github.io/schedule.html Registration is free. Prior to the events you receive a mail with the links to the Zoom meetings. 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. We aspire to be a lively environment for presenting the latest research results, and other contributions. The Trends in Functional Programming in Education workshops are an informal meeting intended for researchers, professors, teachers, and all professionals that use or are interested in the use of functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas, and work in progress on the use of functional programming in education are discussed. We foster a spirit of open discussion by having a review process for publication after the workshop. The program has a lot of interesting talks, possibilities for interaction, and keynote presentations: Trends in Functional Programming in Education keynote speaker: --------------------------------------------------------------- Peter Achten: The Perfect Functional Programming Course Trends in Functional Programming keynote speaker: ------------------------------------------------- Christiaan Baaij: Building a Haskell-to-Hardware compiler: Theory & Practice

1 0

TFPIE 2022 March 16 online - last call for participation
by Elena Machkasova 12 Mar '22

12 Mar '22

Dear All, TFPIE 2022 invites you to attend the conference on March 16 online. The program and the registration link are posted here: https://wiki.tfpie.science.ru.nl/TFPIE2022 Registration is free, but required for the zoom link to be sent. TFPIE is followed by TFP on March 17-18: https://trendsfp.github.io/index.html The registration is the same for the two conferences. More details: The 2022 edition of Trends in Functional Programming in Education will be held *virtually on March 16th 2022*, together with TFP which will be held on March 17-18. Note that *Lambda Days* <https://www.lambdadays.org/lambdadays2022> in Krakow, Poland has been rescheduled to July 28-29, and authors of TFPIE accepted papers are welcome to present their papers at the Lambda Days, in addition to the virtual presentations in March. The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. Hope to see you there! Elena Machkasova -- Dr. Elena Machkasova Associate Professor of Computer Science Division of Science and Mathematics University of Minnesota, Morris Office: Sci 2325 (320) 589-6308 http://cda.morris.umn.edu/~elenam/ Pronouns: she/her/hers or any other

1 0

child thread control design patterns (was: GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus)
by Olaf Klinke 11 Mar '22

11 Mar '22

> Another good option for eternally long running things is to use race. I actually think race and concurrently are the much better go-to functions from the async library. I will often write code like: > > race_ daemonThread mainThread >>= \case > Left _ -> fail "Daemon terminated" > Right a -> return a > > This forks a thread for a daemon, a thread for the main thread, and then waits for either of them to finish. Assuming the daemon should never terminate, if it terminates the main thread will be terminated and the calling thread (e.g., main) will crash. If the other thread terminates early, that's fine, and we assume that's just the program gracefully terminating. In this case, the daemon will be cancelled. > > Ollie That is indeed a neat pattern. What are its advantages/disadvantages? The main thread in my case is the (Yesod) webserver. Perhaps Yesod does exactly what you propose, internally. Currently I use a bracket to kill all child threads when the webserver shuts down, like: main = bracket forkWorkers (traverse_ cancel) (const (warp port site)) Your idiom would be something like this? main = foldr race_ (warp port site) workers I also do want to include the possibility of a child (daemon) thread to crash without crashing the webserver (hence my original question), which your race solution does not cater for. In fact I will have a mix of perpetually running actions and actions that are fired on command of the user and then exit gracefully. Therefore I must save the original IO action somewhere, to be re- executed. And since operations on the child thread are initiated by the Yesod event handler, I can not pass them to the continuation of withAsync. Olaf

3 3

GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus
by Olaf Klinke 09 Mar '22

09 Mar '22

Dear Cafe, I had expected to see ThreadDied in the small example below. But when I compile with ghc --make -threaded -with-rtsopts=-N2 The output is: threadStatus: user error (child thread is crashing!) The status of my child is: ThreadFinished The output is not really a lie. But how do I determine whether a child thread has exited normally or not? Wouldn't you say a call to fail (or any other throwIO) should count as ThreadDied? The documentation of GHC.Conc.forkIO says: "... passes all other exceptions to the uncaught exception handler." and the documentation for GHC.Conc.ThreadStatus says: ThreadDied -- the thread received an uncaught exception One can provoke ThreadDied by using throwTo from the parent thread. So the emphasis in the documentation of ThreadDied should be on the word "received". This is a case of misleading documentation, in my humble opinion. The constructor should not be named ThreadDied because that suggests inclusion of internal reasons. Olaf -- begin threadStatus.hs import Control.Concurrent import GHC.Conc main = mainThread childThread :: IO () childThread = fail "child thread is crashing!" mainThread :: IO () mainThread = do child <- forkIO childThread threadDelay 5000 status <- threadStatus child putStr "The status of my child is: " print status -- end threadStatus.hs

5 6

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.2.2 is not available
by Kazu Yamamoto 07 Mar '22

07 Mar '22

Hi George, FYI: https://twitter.com/kazu_yamamoto/status/1500643489985761282 --Kazu > Thanks Ben > > When I do an install on macos Monterey 12.2.1 (Intel) I get > > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified > > > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari <ben(a)well-typed.com> wrote: > >> >> The GHC developers are very happy to at announce the availability of GHC >> >> 9.2.2. Binary distributions, source distributions, and documentation are >> >> available at downloads.haskell.org: >> >> https://downloads.haskell.org/ghc/9.2.2 >> >> This release includes many bug-fixes and other improvements to 9.2.1 >> including: >> >> * A number of bug-fixes in the new AArch64 native code generator >> >> * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is >> handled >> correctly on platforms lacking support for unaligned memory accesses >> (#21015, #20987). >> >> * Improvements to the compatibility story in GHC's migration to the >> XDG Base Directory Specification (#20684, #20669, #20660) >> >> * Restored compatibility with Windows 7 >> >> * A new `-fcompact-unwind` flag, improving compatibility with C++ >> libraries on >> Apple Darwin (#11829) >> >> * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime >> bounds >> checking of array primops (#20769) >> >> * Unboxing of unlifted types (#20663) >> >> * Numerous improvements in compiler performance. >> >> * Many, many others. See the [release notes] for a full list. >> >> As some of the fixed issues do affect correctness users are encouraged to >> >> upgrade promptly. >> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous >> contributors whose on-going financial and in-kind support has >> facilitated GHC maintenance and release management over the years. >> Moreover, this release would not have been possible without the hundreds >> >> of open-source contributors whose work comprise this release. >> >> As always, do open a [ticket][] if you see anything amiss. >> >> Happy compiling, >> >> - Ben >> >> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [release notes]: >> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.h… >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>

1 0