In lazy functional languages, bottom is typically an element of every type.
While this provides great flexibility, it also comes at a cost.
In this paper we explore the consequences of allowing unpointed types
in a lazy functional language like Haskell.
We use the type (and class) system to keep track of pointedness,
and show the consequences for parametricity and for controlling
evaluation order and unboxing.

A source-level treatment of unboxing, with lots of examples and motivation.
The link with semantic notions is largely superceded (sez we) by our paper.
Also, this version is actually implemented as part of the
Glasgow Haskell Compiler.