April 2024 - Haskell-Cafe

ANN: hledger 1.33
by Simon Michael 19 Apr '24

19 Apr '24

Hi all, I'm pleased to announce hledger 1.33! This release comes a bit later than usual, with help from contributors Jonathan Dowland, Ilja Kocken, Colin Dean, Dmitry Astapov, Vekhir, ShrykeWindgrace, Martijn van der Ven, Michael Rees, aragaer, and hamzashezad. Highlights: `close` enhancements, hledger-ui 'dark' theme, GHC 9.8 support, Apple ARM binaries, and the usual improvements and fixes. - https://github.com/simonmichael/hledger/releases/1.33 - https://hledger.org/relnotes.html#2024-04-18-hledger-133 <https://hledger.org/rel.html#2024-04-18-hledger-133> - https://hledger.org/install Wishing you peace and prosperity, -Simon What is hledger ? Fast, reliable, free, multicurrency, double-entry, plain text accounting software for unix, mac, windows, and the web; built around human-readable, version-controllable plain text files; inspired by and largely compatible with Ledger CLI; convertible to and from Beancount; written in Haskell for reliability and longevity. For help getting started or more info, see https://hledger.org and join our Matrix/IRC chat or mail list: https://hledger.org/support . Newcomers, experts, contributors, sponsors, feedback are welcome! For more about plain text accounting, see https://plaintextaccounting.org .

2 2

Re: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases
by Olaf Klinke 18 Apr '24

18 Apr '24

> ghc should be able to deduce correct use of partial functions and not > give > a warning in such cases, e.g. in 9.8.2 > > if null ys then [] else [(xs,tail ys)]) > > gets a warning > > warning: [GHC-63394] [-Wx-partial] > > but it is clear that this use of tail will never be a problem so IMHO > that > line of code should not get a warning. > > Does anybody know if there is a plan or enhancement request to > eliminate > such warnings? > > Cheers > George The problem is that both partiality checks and checks for incomplete pattern matches are undecidable in general, that is, without assistance the compiler can not infer partiality without risking infinite loops. Checks for incomplete pattern matches could be decidable, if it was not for view patterns, where you can hide arbitrary function applications (think unsafePerformIO) in. Currently GHC plays the safe card, see this thread: https://mail.haskell.org/pipermail/haskell-cafe/2024-January/136545.html With the help of special annotation such as Liquid Haskell you might be able to teach the compiler that your use of partial functions is fine. https://ucsd-progsys.github.io/liquidhaskell/ However, I second Henning in that a -Wx-partial warning hints at the necessity of a code re-factoring. Olaf

1 0

how to integrate a build in automake
by PICCA Frederic-Emmanuel 17 Apr '24

17 Apr '24

Hello, I am trying to build a program with the autotools. At the end I need to link this program with a few libraries with libtool. I wrote something like this but ghc (on Debian stable) does not deal with the default LDFLAGS of the distribution. So I need to generate only the .o files and do the final link by myself. Do you have examples of Makefile.am for an haskell program. Here the current autotool file which I need to modify in order to do the final link... https://repo.or.cz/hkl.git/blob/c2359440baeb38f5acbee91507d1aacf36f1b5bb:/b… thanks for your help. Frederic

1 0

Teach me to cooperate with IOException
by Folsk Pratima 16 Apr '24

16 Apr '24

Consider following C code. ``` int syscall_that_fails (int *errno_here) { *errno_here = 2; return -1; } ``` Now I write the haskell wrapper, first without any error checking. ``` module Complex where import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> c_syscall_that_fails ptr >> return () ``` Now I want to introduce some actual error checking, so at first I simply do ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- peekElemOff ptr 0 case st of (-1) -> throwIO $ userError $ "syscall: " ++ show errno _ -> return () ``` Now, I do not think it is a "user error", it is a real system call error that might or might not be already covered by System.IO.Error. In my case errno is 2, it is "No such file or directory", so it is covered by System.IO.Error and I may just use the library. But my C code may call whatever! What if System.IO does not cover that range of `errno`s? What if I want to distinguish between *my* errors and system errors? In such case I have to introduce my own way to do it. How do I do it? My first wild guess is to introduce my own exception, like this. ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable data CException = LocalCallFailed { cexeption_errno :: Int , cexception_caller :: String } instance Show CException where show (LocalCallFailed errno caller) = caller ++ ": " ++ show errno instance Exception CException foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- peekElemOff ptr 0 case st of (-1) -> throwIO . LocalCallFailed (fromIntegral errno) $ "syscall" _ -> return () ``` And now I ask myself, what if allocaBytes fails? I looked on its code and it does ioError, thus, it will throwIO. If then I need to invoke sysCall, I can not use `try` anymore, because it is not determined what I will catch, LocalCallFailed or IOException. Next, what if I extend the `case of` clause to include some other errors, that are not related to system calls, but are my own? I try to recover, but can not come up with anything better than this... ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable data CException = LocalCallFailed { cexeption_errno :: Int , cexception_caller :: String } | GenericIOException { genericioexception :: IOException } instance Show CException where show (LocalCallFailed errno caller) = caller ++ ": " ++ show errno show (GenericIOException e) = displayException e instance Exception CException ioExceptionToMe :: IO (Either IOException a) -> IO a ioExceptionToMe action = do e0 <- action case e0 of Left e -> throwIO . GenericIOException $ e Right a -> return a tryIO :: IO a -> IO a tryIO action = ioExceptionToMe $ try action foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = tryIO $ allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- tryIO $ peekElemOff ptr 0 case st of (-1) -> throwIO . LocalCallFailed (fromIntegral errno) $ "syscall" _ -> return () ``` Now, this seems to be easily extendable. I can change LocalCallFailed to LocalSyscallFailed and then add something like LocalOwnFailed, which would account for some C error that is not attributed to system calls, and so on. But still, it seems very dumb, because of how I use tryIO. I have to use it on literally every haskell provided IO and... It just does not seem right.

2 1

[ANNOUNCE] GHC 9.6.5 is now available
by Zubin Duggal 16 Apr '24

16 Apr '24

The GHC developers are happy to announce the availability of GHC 9.6.5. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_6_5.html). GHC Blog Post: https://www.haskell.org/ghc/blog/20240416-ghc-9.6.5-released.html This release is primarily a bugfix release addressing some issues found in the 9.6 series. These include: * Bumping the bundled `process` library to 1.6.19.0 to avoid a potential [command injection vulnerability] on Windows for clients of this library. This isn't known to affect GHC itself, but allows users who depend on the installed version of the `process` to avoid the issue. * Fixing a bug resulting in the distributed ``hsc2hs`` wrapper using flags from the compiler build environment (#24050). * Disabling the `-fasm-shortcutting` optimisation with `-O2` as it is known to result in unsoundess and incorrect runtime results in some cases (#24507). * Ensuring we take ``LDFLAGS`` into account when configuring a linker (#24565). * Fixing a bug arising from incorrect parsing of paths containing spaces in the settings file (#24265). * And many more fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. 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. Enjoy! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.5/docs/users_guide/9.6.5-notes.html [command injection vulnerability]: https://github.com/haskell/security-advisories/blob/main/advisories/hackage…

1 0

[ANNOUNCE] GHC 9.10.1-alpha3 is now available
by Ben Gamari 15 Apr '24

15 Apr '24

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.10.1-alpha3 We hope to have this release available via ghcup shortly. GHC 9.10 will bring a number of new features and improvements, including: * The introduction of the `GHC2024` language edition, building upon `GHC2021` with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * [Extension] of LinearTypes to allow linear `let` and `where` bindings ([linear let]) * The implementation of the [exception backtrace proposal], allowing the annotation of exceptions with backtraces, as well as other user-defined context * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes can be found in the [release notes]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status]. This alpha is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later. 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. Cheers, ~ Ben [release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha3/docs/users_guide/9.10.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

runST $ unsafeIOToST $ ioWhatever
by Folsk Pratima 14 Apr '24

14 Apr '24

How wrong is it exactly? Did not get a reply on beginners(a)haskell.org import Control.Exception import Control.Monad.ST import Control.Monad.ST.Unsafe import Data.Word import Foreign.C.String import Foreign.C.String import Foreign.C.Types import Foreign.Marshal import Foreign.Ptr import Foreign.Storable foreign import ccall unsafe "strerror_r_portalbe.c strerror_r_portable" c_strerror_r :: CInt -> Ptr CChar -> CSize -> IO CInt memSet :: Ptr a -> Word8 -> Word32 -> IO (Ptr a) memSet ptr _ 0 = return ptr memSet ptr byte size = do let voidptr = castPtr ptr :: Ptr Word8 acts = map (\i -> pokeByteOff voidptr i byte) [0 .. fromIntegral (size - 1)] mapM_ id acts return ptr strError :: Int -> String strError errnum = runST $ unsafeIOToST ioString where baseSize :: CSize baseSize = 50 ioString = run baseSize run :: CSize -> IO String run size | size > 100000 = throwIO $ userError $ "!!! INTERNAL strError memory leak detected, " ++ "you can not recover !!!" | otherwise = do may <- tryIOString size case may of Just str -> return str Nothing -> run (size + baseSize) tryIOString :: CSize -> IO (Maybe String) tryIOString size = allocaBytes (fromIntegral size) $ \ptr -> do zeroptr <- memSet ptr 0 (fromIntegral size) st <- c_strerror_r (fromIntegral errnum) ptr size -- heuristic case st of 22 -> return . return $ "Unknown error " ++ show errnum 34 -> return Nothing _ -> peekCAString ptr >>= return . return main = mapM_ (putStrLn) $ map strError [1 .. 1000] The C file is #define _POSIX_C_SOURCE 200112L #include <string.h> int strerror_r (int, char *, size_t); int strerror_r_portable (int e, char *c, size_t s) { return strerror_r (e, c, s); } By default GHC picks up GNU version of strerror_r(), I want to pick up the default portable version. I do not know how to make GHC understand my desires.

2 3

Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4)
by Han Joosten 10 Apr '24

10 Apr '24

Hi all, I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4. Using the new version, I get errors like ~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields` I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated! Thanks for reading Cheers, Han Joosten

2 6

IFL 2024: First call for papers
by Mart Lubbers 09 Apr '24

09 Apr '24

======================================================================= IFL 2024 36rd Symposium on Implementation and Application of Functional Languages venue: Radboud University Nijmegen, The Netherlands August 26 - 28 2024 https://ifl24.cs.ru.nl ======================================================================= ### 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 2024 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. ### Industrial track and topics of interest 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 specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - 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 ### Peer-review process Following IFL tradition, IFL 2024 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 chairs 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. 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. ### Important dates Submission deadline of draft papers August 4th, 2024 Notification of acceptance for presentation August 6th, 2024 Early registration deadline August 11th, 2024 Late registration deadline August 21th, 2024 IFL symposium August 26-28, 2024 Submission of papers for proceedings December 1st, 2024 Notification of acceptance February 2nd, 2025 Camera-ready version March 2nd, 2025 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organisation PC Chairs: Mart Lubbers Radboud University, The Netherlands Local Chairs: Peter Achten Radboud University, The Netherlands Sven-Bodo Scholz, Radboud University, The Netherlands ### Program committee: t.b.d. ### Venue IFL 2024 will be held physically in Nijmegen, the Netherlands. See the website for more information. https://ifl24.cs.ru.nl (under construction) ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here.

1 0

Agda Implementors' Meeting XXXVIII: Call for talks and participation
by mukesh tiwari 08 Apr '24

08 Apr '24

Dear all, The thirty-eighth Agda Implementors' Meeting will take place in Swansea, Wales, UK from Monday 13 to Saturday 18 May 2024. Wiki link for more details: https://wiki.portal.chalmers.se/ <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII>agda <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII>/Main/AIMXXXVIII <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII> The meeting aims to bring together people not only developing but also using Agda or even those who are simply interested in it. We will have talks on the implementation details of Agda in the morning and code sprints in the afternoon. You can still submit your proposal for a talk or discussion! There's a (soft) deadline for registration on 14 April 2024 Registration instructions: https://wiki.portal.chalmers.se/ <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII#Registration>agda <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII#Registration> /Main/AIMXXXVIII#Registration <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII#Registration> Best wishes, Anton Setzer ----------------------------------------------------------------------------- Dr Anton Setzer Darllenydd / Reader Ystafell / Room 403 Adran Gyfrifiadureg / Dept. of Computer Science Y Ffowndri Gyfrifiadurol / Computational Foundry Coleg Gwyddoniaeth / College of Science Prifysgol Abertawe/ Swansea University Campws y Bae/ Bay Campus Abertawe / Swansea SA1 8EN DU / UK Rhowch wybod i ni os hoffech dderbyn eich gohebiaeth yn Gymraeg. / Let us know if you would like to receive correspondence in Welsh. Rydym yn croesawu gohebiaeth yn Gymraeg neu yn Saesneg. / We welcome correspondence in Welsh or English. Ni fydd gohebu yn Gymraeg yn arwain at oedi./ Corresponding in Welsh will not lead to a delay.

1 0