procrastinating-variable: Haskell values that cannot be evaluated immediately.
|Versions||1.0, 1.0.1, 1.0.2|
|Dependencies||base (>=3 && <5) [details]|
|Maintainer||Gregory Crosswhite <firstname.lastname@example.org>|
|Uploaded||by GregoryCrosswhite at Mon Jun 8 02:52:13 UTC 2009|
|Downloads||1142 total (9 in the last 30 days)|
|Rating||(no votes yet) [estimated by rule of succession]|
|Status||Docs uploaded by user
Build status unknown [no reports yet]
Hackage Matrix CI
Procrastinating variables (
PVars) are meant to be used in cases where
you want to give someone a value that you do not have available yet,
but will definitely have ready by the time that they need to use it.
PVars have the advantage that you do not make the user of your value
execute some kind of unwrapping routine in order to get access to the
value within. For example, this is useful when you are constructing
closures that you want to go ahead and construct now even though some
of the values that they contain are not available yet.
PVars are implemented with a lazy thunk that reads from
IORef; before the
IORef is written to, it contains "bottom" (an
exception with a descriptive error message) so that an error is raised
in the user code if the variable is accidently accessed before the
value is ready.
PVars are modeled closely on the
IVar implementation in
the ivar-simple package. The major difference is that if you
try to read an
IVar before it has been given a value, it blocks
until the value is available, whereas reading from a
before it is ready raises an exception. The reason behind the
different symantics for
PVar is because if the user
accidently accesses the value too early, you want there to be a
lot of noise to let him or her know about it, rather than
merely blocking the thread indefinitely and causing them to
wonder what went wrong.
For package maintainers and hackage trustees