1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
<!doctype linuxdoc system [
<!ENTITY addr SYSTEM "Addr.sgml">
<!ENTITY bits SYSTEM "Bits.sgml">
<!ENTITY concurrent SYSTEM "Concurrent.sgml">
<!ENTITY dynamic SYSTEM "Dynamic.sgml">
<!ENTITY exception SYSTEM "Exception.sgml">
<!ENTITY foreign SYSTEM "Foreign.sgml">
<!ENTITY glaexts SYSTEM "GlaExts.sgml">
<!ENTITY getopt SYSTEM "GetOpt.sgml">
<!ENTITY ioexts SYSTEM "IOExts.sgml">
<!ENTITY int SYSTEM "Int.sgml">
<!ENTITY ndset SYSTEM "NDSet.sgml">
<!ENTITY numexts SYSTEM "NumExts.sgml">
<!ENTITY pretty SYSTEM "Pretty.sgml">
<!ENTITY st SYSTEM "ST.sgml">
<!ENTITY stable SYSTEM "Stable.sgml">
<!ENTITY weak SYSTEM "Weak.sgml">
<!ENTITY word SYSTEM "Word.sgml">
]>
<!-- ToDo:
o Add indexing support (to linuxdoc)
o Fix citations in html
-->
<article>
<title>The Hugs-GHC Extension Libraries
<author>The Hugs/GHC Team
<date>January 1999
<abstract>
Hugs and GHC provide a common set of libraries to aid portability.
This document specifies the interfaces to these libraries and documents
known differences.
</abstract>
<toc>
<sect> <idx/Naming conventions/
<label id="sec:Naming conventions">
<p>
The set of interfaces specified in this document try to adhere to the
following naming conventions:
<itemize>
<item>
Actions that create a new values have the prefix <tt/new/ followed by
the name of the type of object they're creating, e.g., <tt/newIORef/,
<tt/newChan/ etc.
<item>
Operations that read a value from a mutable object are prefixed with
<tt/read/, and operations that update the contents have the prefix
<tt/write/, e.g., <tt/readChan/, <tt/readIOArray/.
Notes:
<itemize>
<item>
This differs from the convention used to name the operations for
reading and writing to a file <tt/Handle/, where <tt/get/ and <tt/put/
are used instead.
<item>
Operations provided by various concurrency abstractions, e.g., <tt/MVar/,
<tt/CVar/ , also deviate from this naming scheme. This is perhaps
defensible, since the read and write operations have additional
behaviour, e.g., <tt/takeMVar/ tries to read the current value
of an <tt/MVar/, locking it if it succeeds.
</itemize>
<item>
Conversions operators have the form <tt/AToB/ where <tt/A/ and <tt/B/
are the types we're converting between.
<item>
Operations that lazily read values from a mutable object/handle, have
the form <tt/getXContents/, e.g., <tt/Channel.getChanContents/ and
<tt/IO.hGetContents/. (OK, so the latter isn't called
<tt/getHandleContents/, but you hopefully get the picture.)
</itemize>
<!-- ========================= -->
&addr
&bits
&concurrent
&dynamic
&exception
&foreign
&getopt
&glaexts
&ioexts
&int
&numexts
&pretty
&st
&stable
<sect> <idx/LazyST/
<label id="sec:LazyST">
<p>
This library is identical to <tt/ST/ except that the <tt/ST/ monad
instance is <em/lazy/. The lazy ST monad tends to be more prone to
space leaks than the strict version, so most programmers will use the
former unless laziness is explicitly required. <tt/LazyST/ provides
two additional operations:
<tscreen> <verb>
lazyToStrictST :: LazyST.ST s a -> ST.ST s a
strictToLazyST :: ST.ST s a -> LazyST.ST s a
</verb> </tscreen>
These are used to convert between lazy and strict state threads. The
semantics with respect to laziness are as you would expect: the strict
state thread passed to <tt/strictToLazyST/ is not performed until the
result of the lazy state thread it returns is demanded.
&weak
&word
<!-- ========================= -->
<biblio files="refs" style="abbrv">
</article>
|
