CLC proposals RFC

TeofilC · June 30, 2026, 2:43pm

CLC proposals are the process for changing the interface of base. They have a broad impact and often benefit from the perspectives of members of the community, although the decision on whether to accept or reject them lies solely with the CLC.

I’m going to start posting links to new CLC proposals in this thread in order to increase awareness for people who aren’t prepared to subscribe to the hosepipe of watching the CLC repo via GitHub notifications.

Please do not reply in this thread, and engage in the respective proposal issue on GitHub instead

TeofilC · June 30, 2026, 2:43pm

github.com/haskell/core-libraries-committee

Extend ByteArray resizing functions

opened 12:21PM - 20 Jun 26 UTC

L0neGamer

The operator to resize mutable bytearrays ([resizeMutableByteArray#](https://hac…kage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Base.html#v:resizeMutableByteArray-35-)) currently states that it will attempt to resize the mutable byte array in place, and if it cannot do that it will allocate an unpinned byte array to copy into. _note: In this proposal, we will refer to only arrays that have been explicitly pinned (with `newPinnedByteArray#` or `newAlignedPinnedByteArray#`); pinning from being large or in a compact region isn't relevant here_ This proposals suggests that we add the following primops to `GHC(.Internal)?.Base` to allow the programmer to more explicitly control the pinnedness of the resultant mutable byte array when in-place resizing cannot take place: - `resizeMutableByteArrayKeepPinned#` - make the copy-into array the same pinnedness as the input array - `resizeMutableByteArrayPreferPinned#` - make the copy-into array pinned - `resizeMutableByteArrayPreferUnpinned#` - make the copy-into array unpinned Additionally, `resizeMutableByteArray#` will be defined as `resizeMutableByteArray# = resizeMutableByteArrayPreferUnpinned#`. This allows developers the greatest control possible over the mutable byte arrays they use, reducing the checks that they would need to do to check if an array they have is pinned or not. ### Alternatives - change resizeMutableByteArray# to maintain pinnedness (since it does not guarantee which pinnedness it uses, this is like saying "it's a coin flip" and then only landing on heads). - use a function that takes an enum/int to determine behavior instead of three new functions ### Additional notes GHC MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/16010 GHC Issue: https://gitlab.haskell.org/ghc/ghc/-/issues/27244 GHC User Guide Pinned ByteArrays: https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/ffi.html#pinned-byte-arrays

TeofilC · June 30, 2026, 2:43pm

github.com/haskell/core-libraries-committee

Add withEmptyCallStack to GHC.Stack (part of the new -Wdefaulted-callstack GHC warning)

opened 04:03PM - 21 Jun 26 UTC

arybczak

This is a small part of https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1617…4 that needs a CLC proposal since it modifies `base`. To recap: this MR adds a new warning `-Wdefaulted-callstack` (disabled by default) which warns the user about calls to functions that include `HasCallStack` constraint in scope where this constraint is not available, i.e. it's implicitly defaulted to the empty stack. This is somewhat similar to the [require-callstack](https://hackage.haskell.org/package/require-callstack) library, except usage of require-callstack needs code change (using [`RequireCallStack`](https://hackage.haskell.org/package/require-callstack-0.2.0.1/docs/RequireCallStack.html#t:RequireCallStack) instead of `HasCallStack`) and forces all downstream users to explicitly use [`provideCallStack`](https://hackage.haskell.org/package/require-callstack-0.2.0.1/docs/RequireCallStack.html#v:provideCallStack) to discharge it, which will usually be too heavy of a cost (I considered using require-callstack in some of my packages, but ultimately decided against it for these reasons). `-Wdefaulted-callstack` solves this problem, because now you can ensure that your library propagates `HasCallStack` constraints properly within your package, while it will continue to work as usual for people who don't bother with call stacks for whatever reason. However, if the warning is enabled project-wide (which is what you want if you want to ensure good call stack propagation), for it to be usable it needs the addition of the following function to GHC.Stack: ```haskell -- | Explicitly bring the empty call stack into scope. -- -- Mostly useful for silencing warnings generated by @-Wdefaulted-callstack@ in -- places such as: -- -- - The body of a class method in an instance of an externally defined type -- class whose type signature doesn't contain a 'HasCallStack' constraint. -- -- - The body of the @main@ function. withEmptyCallStack :: (HasCallStack => a) -> a withEmptyCallStack do_this = let ?callStack = emptyCallStack in do_this ``` It's needed to suppress the warning in the two cases haddock describes. For the record, the first case describes the following scenario: External package: ```haskell module External class C a where foo :: a -> IO () ``` My package: ```haskell {-# OPTIONS_GHC -Wdefaulted-callstack #-} module Local where import External data X = X instance C X where -- Call to `error` emits the warning, no way to eliminate -- since I don't control type signature of `foo`. foo X = error "x" ``` It needs to be ```haskell instance C X where foo X = withEmptyCallStack $ do -- no warning here error "x" ``` This is a small function (its usage in scope without `HasCallStack` compiles to the same code GHC would generate without it, it simply makes the empty call stack defaulting explicit) with a very distinct name (hoogle finds no such functions in stackage packages), so I hope there will be no issues with including it.

TeofilC · June 30, 2026, 2:44pm

github.com/haskell/core-libraries-committee

Remove Control.Exception.nonTermination et al.

opened 11:15PM - 21 Jun 26 UTC

bgamari-positron

For historical reasons various modules expose a number of bindings used by the r…untime system and compiler to raise various exceptions: ```haskell module Control.Exception.Base where recSelError, recConError, impossibleError, impossibleConstraintError, nonExhaustiveGuardsError, patError, noMethodBindingError, typeError, nonTermination, nestedAtomically, noMatchingContinuationPrompt :: SomeException module GHC.IO.Exception where blockedIndefinitelyOnMVar, blockedIndefinitelyOnSTM, allocationLimitExceeded :: SomeException cannotCompactFunction, cannotCompactPinned, cannotCompactMutable :: SomeException heapOverflow, stackOverflow :: SomeException ``` Users have no business using these; they previously only existed as a way to define these exceptions for use by the runtime. Happily, they now needn't be exposed from `base` now since `ghc-internal` exists. They should be removed.

TeofilC · June 30, 2026, 2:44pm

github.com/haskell/core-libraries-committee

Introduce ThrownBy exception annotation

opened 01:45PM - 29 Jun 26 UTC

bgamari-positron

In concurrent programs asynchronous exceptions can result in non-trivial action-…at-a-distance, resulting in hard-to-reason-about control flow in exceptional situations. This leads to challenging debugging scenarios which GHC/Haskell currently offers few good tools to characterize. However, the exception annotation mechanism provides a reasonable path to improving this situation. Specifically, a new variety of `ExceptionAnnotation`: ```haskell module Control.Exception where newtype ThrownFrom = ThrownFrom Backtraces instance Show ThrownFrom instance ExceptionAnnotation ThrownFrom ``` `Control.Exception.throwTo` to be implemented as follows: ```haskell throwTo :: Exception e => ThreadId -> e -> IO () throwTo (ThreadId tid) ex | backtraceDesired ex = do bts <- ThrownFrom <$> collectBacktraces throwTo_ $ addExceptionContext bts $ toException ex | otherwise = throwTo_ $ toException ex throwTo_ :: Exception e => ThreadId -> e -> IO () throwTo_ (ThreadId tid) ex = IO $ \ s -> case (killThread# tid ex' s) of s1 -> (# s1, () #) ``` This gives the developer a clear chain of causality between their thread dying and the exception from which the death stemmed.

jaror · July 1, 2026, 12:57pm

2 posts were split to a new topic: Split base into GHC and non-GHC parts