- Haskell-Cafe - Haskell.org

ghc should be able to deduce correct use of partial functions and not give a warning in such cases
by George Colpitts 21 Apr '24

21 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

8 17

Student Research Competition (SRC) at ICFP 2024
by Favonia 21 Apr '24

21 Apr '24

ICFP 2024 Student Research Competition Call for Submissions ICFP 2024 invites students to participate in the Student Research Competition in order to present their research and get feedback from prominent members of the programming language research community. The SRC consists of three rounds: * Submission of an extended abstract * Poster session at ICFP 2024 * Finalists' presentations at ICFP 2024 During the first round students submit an extended abstract detailing their research to be reviewed by the program committee. Those students whose abstracts get accepted advance to the poster session round which will take place during ICFP 2024. Winners of the poster session advance to the next round, where they will give a 5-minute presentation about their work on the ICFP main stage in front of a live audience. ### IMPORTANT DATES AND TIMES * Submission Deadline: 23 May 2024 (Thursday) * Author Notification: 14 June 2024 (Friday) 12:00 PM CST * ICFP 2024 Conference in Milan, Italy: 2 September 2024 (Monday) - 7 September 2024 (Saturday) ### SUBMISSION OF EXTENDED ABSTRACTS * Submission Website: https://icfp24src.hotcrp.com Each submission (referred to as "abstract" below) should include the student author's name and e-mail address; institutional affiliation; research advisor's name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and/or part of a larger group project, the abstract should make clear what the student's role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp24.sigplan.org/track/icfp-2024-student-research-competition

1 0

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

20 Apr '24

> > So your code is essentially pattern matching on a list to decide ..., then pattern matching on the Bool to split between two cases, then pattern matching on the list again. If you had kept the result of the first pattern match there would be no need for the latter two. > > Essentially the problem is "boolean blindness" ... > > This style of coding is generally more readable, maintainable, and less error-prone. ... > +1 to Ben's wise advice. +1 to "more readable". Haskell is a 'functional language' does not mean everything everywhere has to be expressed only through functions. Perhaps we should promote 'Algebraic data types' (yay mathy!) and 'pattern matching' right up front on the 'Features' section of Haskell.org? AntC

1 0

cabal install: Failed to download aeson-2.2.1.0
by Johannes Waldmann 19 Apr '24

19 Apr '24

Dear Cafe. "cabal install" sometimes cannot download aeson. This happens repeatedly (in recent days) but it's not fully reproducible. Example where it happens in CI (image haskell-slim) https://git.imn.htwk-leipzig.de/waldmann/pure-matchbox/-/jobs/41533 What might be the reason? - J.

1 0

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