]>
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 &glaexts &ioexts &int &numexts &pretty &st <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>