Go to the first, previous, next, last section, table of contents.


The type `Array# elt' is the type of primitive, unboxed arrays of values of type `elt'.
type Array# elt
`Array#' is more primitive than a Haskell array -- indeed, the Haskell `Array' interface is implemented using `Array#' -- in that an `Array#' is indexed only by `Int#'s, starting at zero. It is also more primitive by virtue of being unboxed. That doesn't mean that it isn't a heap-allocated object -- of course, it is. Rather, being unboxed means that it is represented by a pointer to the array itself, and not to a thunk which will evaluate to the array (or to bottom). The components of an `Array#' are themselves boxed. The type `ByteArray#' is similar to `Array#', except that it contains just a string of (non-pointer) bytes.
type ByteArray#
Arrays of these types are useful when a Haskell program wishes to construct a value to pass to a C procedure. It is also possible to use them to build (say) arrays of unboxed characters for internal use in a Haskell program. Given these uses, `ByteArray#' is deliberately a bit vague about the type of its components. Operations are provided to extract values of type `Char#', `Int#', `Float#', `Double#', and `Addr#' from arbitrary offsets within a `ByteArray#'. (For type `Foo#', the ith offset gets you the ith `Foo#', not the `Foo#' at byte-position i. Mumble.) (If you want a `Word#', grab an `Int#', then coerce it.) Lastly, we have static byte-arrays, of type `Addr#' [mentioned previously]. (Remember the duality between arrays and pointers in C.) Arrays of this types are represented by a pointer to an array in the world outside Haskell, so this pointer is not followed by the garbage collector. In other respects they are just like `ByteArray#'. They are only needed in order to pass values from C to Haskell.
Go to the first, previous, next, last section, table of contents.