November 2023 - ghc-devs

Request for approval of account
by Mark Seemann 24 Jun '25

24 Jun '25

Hello I’d like to report a bug in GHC because an error message tells me to do so. In order to do that, I’m trying to follow the guidelines in https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug, so I’ve created an account. The next step, as I understand it, is to use this mailing list to request approval for he account. I’m hereby doing that. TIA Mark Seemann

2 1

Reinstallable - base
by Simon Peyton Jones 07 Aug '24

07 Aug '24

Dear GHC devs Given the now-agreed split between ghc-internal and base <https://github.com/haskellfoundation/tech-proposals/pull/51>, what stands in the way of a "reinstallable base"? Specifically, suppose that - GHC 9.8 comes out with base-4.9 - The CLC decides to make some change to `base`, so we get base-4.10 - Then GHC 9.10 comes out with base-4.10 I think we'd all like it if someone could use GHC 9.10 to compile a library L that depends on base-4.9 and either L doesn't work at all with base-4.10, or L's dependency bounds have not yet been adjusted to allow base-4.10. We'd like to have a version of `base`, say `base-4.9.1` that has the exact same API as `base-4.9` but works with GHC 9.10. Today, GHC 9.10 comes with a specific version of base, *and you can't change it*. The original reason for that was, I recall, that GHC knows the precise place where (say) the type Int is declared, and it'll get very confused if that data type definition moves around. But now we have `ghc-internal`, all these "things that GHC magically knows" are in `ghc-internal`, not `base`. *Hence my question: what (now) stops us making `base` behave like any other library*? That would be a big step forward, because it would mean that a newer GHC could compile old libraries against their old dependencies. (Some changes would still be difficult. If, for example, we removed Monad and replaced it with classes Mo1 and Mo2, it might be hard to simulate the old `base` with a shim. But getting 99% of the way there would still be fantastic.) Simon

15 24

Upcoming GHC 9.4.8 release
by Zubin Duggal 10 Jan '24

10 Jan '24

Hi all, We hope to prepare the 9.4.8 release in the coming weeks. This will likely be the final release in the 9.4 series. The major patches currently slated for inclusion into the 9.4.8 are: 1. A process submodule bump to 1.6.17.0 avoiding segfaults on Darwin (https://github.com/haskell/process/issues/295) 2. A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11178) 3. A fix for a packaging bug so that we can ensure all released binaries and bundled libraries are built with `-split-sections` enabled (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9492) If you would like any patches to be considered for inclusion in this release please ensure that the corresponding Merge Requests are marked with the ~"backport needed:9.4" by **the end of this week**. Please note that we will be quite conservative with the changes we accept for this branch at this point in its lifecycle. The current set of all MRs being considered for inclusion can be viewed at https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&lab… Thanks, Zubin

2 4

Problems building cabal-install?
by Viktor Dukhovni 26 Nov '23

26 Nov '23

I am having a rather unexpected difficulty building older versions of cabal-install. The invariably run into conflicts between "Cabal" and "Cabal-syntax". The latter shows up as a dependency of "Cabal" on hackage, but not in the upstream Git repo. Is there is there some sort of problem with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... It is odd for these to have "Cabal-syntax 3.10.*" as a dependency, with conflicting definitions. -- Viktor.

2 6

Upcoming GHC 9.6.4 release
by Zubin Duggal 24 Nov '23

24 Nov '23

Hi all, We are planning a release in the 9.6 series before Christmas, with a preliminary ETA of 15th December. Release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24017 Please use this ticket to request any submodule bumps or for any other discussion related to the release. If you would like any patches to be considered for inclusion in this release please ensure that the corresponding Merge Requests are marked with the ~"backport needed:9.6" label. The current set of all MRs being considered for inclusion can be viewed at https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&lab… Cheers, Zubin

2 3

Docs for RTS option -I
by Bryan Richter 22 Nov '23

22 Nov '23

The original docs are here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.h… They raised more questions than answers for me, so I took a stab at rewriting them, and sprinkled in some questions where I need better understanding. Anyone care to fill in my blanks? ----------------- Set the amount of idle time which must pass before an idle GC is performed. Setting -I0 disables the idle GC. The idle GC only affects the threaded and SMP versions of the RTS (see -threaded, Options affecting linking). When the idle GC is enabled, a major GC is automatically performed if the runtime has been idle (i.e., no Haskell computation has been running) for the specified period of time. For an interactive application, it is probably a good idea to use the idle GC, because this will allow finalizers to run and deadlocked threads to be detected in the idle time when no Haskell computation is happening. [Why is this a good thing? What happens when the idle GC is disabled?] Also, it will mean that a GC is less likely to happen when the application is busy, so application responsiveness may be improved. However, if the amount of live data in the heap is particularly large, then the idle GC can cause a significant penalty to responsiveness. [Why? Is it because the idle GC was delayed by waiting for some idle time, and thus has more work to do?]. Conversely, too small of an interval could adversely affect interactive responsiveness [How? And how is this worse than having idle GC disabled? What is the actual behavior when it's disabled, anyway?] The idle period timer only resets after some activity by a Haskell thread. Therefore, once an idle GC is triggered, another one won't be scheduled until more work is performed. This is an experimental feature. Please let us know if it causes problems and/or could benefit from further tuning.

2 3

Account Approval
by Matthew Hammond 20 Nov '23

20 Nov '23

Hello everyone, I’ve been working on my own Haskell interpreter and found a strange case that GHC seems to hang on until it overflows, where I would expect a proper error. I’m fairly new to Haskell, and completely new to the GHC codebase, but I figured I might as well give it a shot! I’ve made an account on the GitLab, and I’m requesting approval please. Thanks, Matthew Hammond.

2 1

Re: Support conversion from (UArray i Word8) to ShortByteString?
by Matthew Craven 14 Nov '23

14 Nov '23

Viktor, Your proposed `arrayToByteArray` seems plausible. Your proposed `byteArrayToShort` is just the newtype-constructor `ShortByteString` which is exposed from Data.ByteString.Short since bytestring-0.12.0.0. > An alternative is to add a tailored version of the UArray and STUArray > APIs to 'MutableByteArray' by extending the rather limited API of > 'Data.Array.Byte': How does this compare to the interface provided by primitive:Data.Primitive.ByteArray? Their `runByteArray` is your `runMutableByteArray`. > The 'ShortByteString' type in the "bytestring" package has seen some > singnificant improvement recently, and yet its API is still noticeably > limited in comparison to its pinned, I/O friendly 'ByteString' elder > sibling. > > One of the limitations is that that there are fewer ways to construct a > 'ShortByteString' object. One often has to restort to constructing a > pinned ByteString, and then copy. (There no "ST" Builders that write > to resizable MutableByteArrays instead of raw memory pointers). > > Meanwhile, under-the covers, both the "UArray i Word8" type and > 'ShortByteString' hold an immutable 'ByteArray', and the STUArray API > provides a flexible "UArray" construction interface. > > Would it be reasonable to "bridge" the two APIs: > > Data.Array.Unboxed: (re-export from Data.Array.Base) > import Data.Array.Byte > > arrayToByteArray :: UArray i Word8 -> ByteArray > arrayToByteArray (UArray _ _ _ ba#) = ByteArray ba# > {-# INLINE arrayToByArrray #-} > > Data.ByteString.Short: (re-export from Data.ByteString.Short.Internal) > byteArrayToShort :: ByteArray -> ShortByteString > byteArrayToShort = coerce > {-# INLINE byteArrayToShort #-} > > It would then be possible to write: > > short = byteArrayToShort $ arrayToByteArray $ runSTUArray m > where > m = do > a <- newArray (0, last) 0 -- zero fill > sequence_ [ writeArray a ix e | (ix, e) <- generator ] > > and generate the bytes of a 'ShortByteString' from an arbitrary > computation, possibly merging multiple inputs into some bytes by using > the recently introduced "modifyArray" (or explicit read/modify/write). > > Any thoughts about the wisdom or lack thereof of this proposal? > > An alternative is to add a tailored version of the UArray and STUArray > APIs to 'MutableByteArray' by extending the rather limited API of > 'Data.Array.Byte': > > runMutableByteArray :: (forall s. ST s (MutableByteArray s)) > -> ByteArray > runMutableByteArray m = runST $ m >>= freezeMutableByteArray > > freezeMutableByteArray (MutableByteArray mba#) = > ST $ \s -> case unsafeFreezeByteArray# mba# s of > (# s', ba# #) -> (# s', ByteArray ba# #) > > Since "Data.Array.Byte" is an "array" (rather than string) interface, it > could have a richer set of indexed read/write/modify primitives along > the lines of those found in "Data.Array.STUArray", but specialised to > 'Word8' elements and implicit zero-based integer indexing. > > The flexible construction I seek would then be via "Data.Array.Bytes", > rather than the somewhat too general index and value types from UArray. > > short = byteArrayToShort $ runMutableByteArray m > where > m = do > a <- newByteArray size 0 -- 0 fill > sequence_ [ writeByteArray a ix e | (ix, e) <- generator ] > > In this scenario, the indexed-mutation of ShortByteStrings under > construction, or indexed-mutation of copies for various transformations, > could live in Data.Array.Byte, with ShortByteString and various > applications leveraging the random-access mutation (and resizing, ...) > to implement higher level operations. > > -- > Viktor.

2 1

Support conversion from (UArray i Word8) to ShortByteString?
by Viktor Dukhovni 11 Nov '23

11 Nov '23

The 'ShortByteString' type in the "bytestring" package has seen some singnificant improvement recently, and yet its API is still noticeably limited in comparison to its pinned, I/O friendly 'ByteString' elder sibling. One of the limitations is that that there are fewer ways to construct a 'ShortByteString' object. One often has to restort to constructing a pinned ByteString, and then copy. (There no "ST" Builders that write to resizable MutableByteArrays instead of raw memory pointers). Meanwhile, under-the covers, both the "UArray i Word8" type and 'ShortByteString' hold an immutable 'ByteArray', and the STUArray API provides a flexible "UArray" construction interface. Would it be reasonable to "bridge" the two APIs: Data.Array.Unboxed: (re-export from Data.Array.Base) import Data.Array.Byte arrayToByteArray :: UArray i Word8 -> ByteArray arrayToByteArray (UArray _ _ _ ba#) = ByteArray ba# {-# INLINE arrayToByArrray #-} Data.ByteString.Short: (re-export from Data.ByteString.Short.Internal) byteArrayToShort :: ByteArray -> ShortByteString byteArrayToShort = coerce {-# INLINE byteArrayToShort #-} It would then be possible to write: short = byteArrayToShort $ arrayToByteArray $ runSTUArray m where m = do a <- newArray (0, last) 0 -- zero fill sequence_ [ writeArray a ix e | (ix, e) <- generator ] and generate the bytes of a 'ShortByteString' from an arbitrary computation, possibly merging multiple inputs into some bytes by using the recently introduced "modifyArray" (or explicit read/modify/write). Any thoughts about the wisdom or lack thereof of this proposal? An alternative is to add a tailored version of the UArray and STUArray APIs to 'MutableByteArray' by extending the rather limited API of 'Data.Array.Byte': runMutableByteArray :: (forall s. ST s (MutableByteArray s)) -> ByteArray runMutableByteArray m = runST $ m >>= freezeMutableByteArray freezeMutableByteArray (MutableByteArray mba#) = ST $ \s -> case unsafeFreezeByteArray# mba# s of (# s', ba# #) -> (# s', ByteArray ba# #) Since "Data.Array.Byte" is an "array" (rather than string) interface, it could have a richer set of indexed read/write/modify primitives along the lines of those found in "Data.Array.STUArray", but specialised to 'Word8' elements and implicit zero-based integer indexing. The flexible construction I seek would then be via "Data.Array.Bytes", rather than the somewhat too general index and value types from UArray. short = byteArrayToShort $ runMutableByteArray m where m = do a <- newByteArray size 0 -- 0 fill sequence_ [ writeByteArray a ix e | (ix, e) <- generator ] In this scenario, the indexed-mutation of ShortByteStrings under construction, or indexed-mutation of copies for various transformations, could live in Data.Array.Byte, with ShortByteString and various applications leveraging the random-access mutation (and resizing, ...) to implement higher level operations. -- Viktor.

1 0

Nofib
by Simon Peyton Jones 11 Nov '23

11 Nov '23

Dear devs Building 'nofib' with HEAD fails with real/scs/Parse.hs:40:19: error: [GHC-87543] Ambiguous occurrence ‘List’. It could refer to either ‘Data.List.List’, imported from ‘Data.List’ at real/scs/Parse.hs:4:1-16 (and originally defined in ‘GHC.Types’), or ‘Types.List’, imported from ‘Types’ at real/scs/Parse.hs:8:1-12. | 40 | list :: Parser List | ^^^^ This is because of a change in the export list of Data.List. The fix is easy (hide the import of List). But I don't know how to update nofib and the subdmodule magic to make HEAD pick the new version. Could anyone possible execute on this? Thanks Simon

3 3