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.