HORIZON HASKELLDocslts/ghc-9.10.xc74966e2026-09-27Search names, modules, packages, or :: a typeCtrl K

GHC 9.10.3 · lts/ghc-9.10.x · c74966e · 2026-09-27

Modulebasement-0.0.16Haskell2010

Basement.Sized.Block

A Nat-sized version of Block

  • 2 types
  • 33 values
  • Packagebasement-0.0.16
  • Exports35
  • LanguageHaskell2010
  • LicenceBSD-3-Clause
  • SourceBlock.hs
newtypenewtype BlockN (n :: Nat) a
#

Sized version of Block

Instances12TryFrom, Eq, Data, Ord, Show, NormalForm, …
valuewithPtr
  1. :: (PrimMonad prim, KnownNat n)
  2. => BlockN n ty
  3. -> Ptr ty -> prim a
  4. -> prim a
#

Get a Ptr pointing to the data in the Block.

Since a Block is immutable, this Ptr shouldn't be to use to modify the contents

If the Block is pinned, then its address is returned as is, however if it's unpinned, a pinned copy of the Block is made before getting the address.

valuewithMutablePtr
  1. :: (PrimMonad prim, KnownNat n)
  2. => MutableBlockN n ty (PrimState prim)
  3. -> Ptr ty -> prim a
  4. -> prim a
#

Create a pointer on the beginning of the MutableBlock and call a function f.

The mutable block can be mutated by the f function and the change will be reflected in the mutable block

If the mutable block is unpinned, a trampoline buffer is created and the data is only copied when f return.

it is all-in-all highly inefficient as this cause 2 copies

valuewithMutablePtrHint
  1. :: (PrimMonad prim, KnownNat n)
  2. => Bool

    hint that the buffer doesn't need to have the same value as the mutable block when calling f

  3. -> Bool

    hint that the buffer is not supposed to be modified by call of f

  4. -> MutableBlockN n ty (PrimState prim)
  5. -> (Ptr ty -> prim a)
  6. -> prim a
#

Same as withMutablePtr but allow to specify 2 optimisations which is only useful when the MutableBlock is unpinned and need a pinned trampoline to be called safely.

If skipCopy is True, then the first copy which happen before the call to f, is skipped. The Ptr is now effectively pointing to uninitialized data in a new mutable Block.

If skipCopyBack is True, then the second copy which happen after the call to f, is skipped. Then effectively in the case of a trampoline being used the memory changed by f will not be reflected in the original Mutable Block.

If using the wrong parameters, it will lead to difficult to debug issue of corrupted buffer which only present themselves with certain Mutable Block that happened to have been allocated unpinned.

If unsure use withMutablePtr, which default to *not* skip any copy.