summaryrefslogtreecommitdiff
path: root/libraries/base/GHC/IO/Exception.hs
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Data.List specialization to []"Matthew Pickering2021-12-031-1/+1
| | | | | | | | | | This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2. This implements the first step in the plan formulated in #20025 to improve the communication and migration strategy for the proposed changes to Data.List. Requires changing the haddock submodule to update the test output.
* Data.List specialization to []Oleg Grenrus2021-04-011-1/+1
| | | | | | | - Remove GHC.OldList - Remove Data.OldList - compat-unqualified-imports is no-op - update haddock submodule
* Don't lose parentheses in show SomeAsyncExceptionNathan Collins2019-05-291-1/+1
|
* Remove OPTIONS_HADDOCK hide in favour for not-homeAdam Sandberg Eriksson2019-01-061-1/+1
| | | | GHC Trac Issues: #15447
* Fix ambiguous/out-of-scope Haddock identifiersAlec Theriault2018-08-211-1/+2
| | | | | | | | | | | | | | | | | This drastically cuts down on the number of Haddock warnings when making docs for `base`. Plus this means more actual links end up in the docs! Also fixed other small mostly markup issues in the documentation along the way. This is a docs-only change. Reviewers: hvr, bgamari, thomie Reviewed By: thomie Subscribers: thomie, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5055
* Correct FixIOException's @since annotation retroactivelyRyan Scott2018-04-131-2/+5
| | | | | | | | | | | | | | | | | | | | Summary: In D4113, a `FixIOException` data type was added with a `@since TODO` annotation, but it seems that `TODO` made it out into `base-4.11` itself. I've (retroactively) fixed this and added an entry to the `base-4.11` entry in the `changelog`. Test Plan: Read it Reviewers: dfeuer, hvr, bgamari Reviewed By: dfeuer Subscribers: thomie, carter GHC Trac Issues: #14356, #15025 Differential Revision: https://phabricator.haskell.org/D4578
* Add @since annotations for derived instances in baseChaitanya Koparkar2018-03-021-2/+6
| | | | | | | | | | | | | | Test Plan: ./validate Reviewers: hvr, goldfire, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11767 Differential Revision: https://phabricator.haskell.org/D4452
* Add custom exception for fixIODavid Feuer2017-11-021-0/+10
| | | | | | | | | | | | | | | | Traditionally, `fixIO f` throws `BlockedIndefinitelyOnMVar` if `f` is strict. This is not particularly friendly, since the `MVar` in question is just part of the way `fixIO` happens to be implemented. Instead, throw a new `FixIOException` with a better explanation of the problem. Reviewers: austin, hvr, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14356 Differential Revision: https://phabricator.haskell.org/D4113
* Fix comment for compact regionTakenobu Tani2017-05-041-1/+1
| | | | | | | | | | | | | | | | | | | There were old module names: * Data.Compact -> GHC.Compact * Data.Compact.Internal -> GHC.Compact This commit is for ghc-8.2 branch. Test Plan: build Reviewers: austin, bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3522
* Throw an exception on heap overflowDemi Obenour2017-01-101-1/+8
| | | | | | | | | | | | | | | | | This changes heap overflow to throw a HeapOverflow exception instead of killing the process. Test Plan: GHC CI Reviewers: simonmar, austin, hvr, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2790 GHC Trac Issues: #1791
* Make CompactionFailed a newtypeRyan Scott2016-12-201-2/+2
|
* Overhaul of Compact Regions (#12455)Simon Marlow2016-12-071-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit makes various improvements and addresses some issues with Compact Regions (aka Compact Normal Forms). This was the most important thing I wanted to fix. Compaction previously prevented GC from running until it was complete, which would be a problem in a multicore setting. Now, we compact using a hand-written Cmm routine that can be interrupted at any point. When a GC is triggered during a sharing-enabled compaction, the GC has to traverse and update the hash table, so this hash table is now stored in the StgCompactNFData object. Previously, compaction consisted of a deepseq using the NFData class, followed by a traversal in C code to copy the data. This is now done in a single pass with hand-written Cmm (see rts/Compact.cmm). We no longer use the NFData instances, instead the Cmm routine evaluates components directly as it compacts. The new compaction is about 50% faster than the old one with no sharing, and a little faster on average with sharing (the cost of the hash table dominates when we're doing sharing). Static objects that don't (transitively) refer to any CAFs don't need to be copied into the compact region. In particular this means we often avoid copying Char values and small Int values, because these are static closures in the runtime. Each Compact# object can support a single compactAdd# operation at any given time, so the Data.Compact library now enforces mutual exclusion using an MVar stored in the Compact object. We now get exceptions rather than killing everything with a barf() when we encounter an object that cannot be compacted (a function, or a mutable object). We now also detect pinned objects, which can't be compacted either. The Data.Compact API has been refactored and cleaned up. A new compactSize operation returns the size (in bytes) of the compact object. Most of the documentation is in the Haddock docs for the compact library, which I've expanded and improved here. Various comments in the code have been improved, especially the main Note [Compact Normal Forms] in rts/sm/CNF.c. I've added a few tests, and expanded a few of the tests that were there. We now also run the tests with GHCi, and in a new test way that enables sanity checking (+RTS -DS). There's a benchmark in libraries/compact/tests/compact_bench.hs for measuring compaction speed and comparing sharing vs. no sharing. The field totalDataW in StgCompactNFData was unnecessary. Test Plan: * new unit tests * validate * tested manually that we can compact Data.Aeson data Reviewers: gcampax, bgamari, ezyang, austin, niteria, hvr, erikd Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2751 GHC Trac Issues: #12455
* Add @since annotations to base instancesSeraphime Kirkovski2016-06-061-0/+22
| | | | | | | | | | | | | | | | | | Add @since annotations to instances in `base`. Test Plan: * ./validate # some commets shouldn't break the build * review the annotations for absurdities. Reviewers: ekmett, goldfire, RyanGlScott, austin, hvr, bgamari Reviewed By: RyanGlScott, hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2277 GHC Trac Issues: #11767
* Add -prof stack trace to assertSimon Marlow2016-01-131-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: So that assertion failures have full call stack information attached when using `ghc -fexternal-interpreter -prof`. Here's one I just collected by inserting a dummy assert in Happy: ``` *** Exception: Assertion failed CallStack (from ImplicitParams): assert, called at ./First.lhs:37:11 in main:First CallStack (from -prof): First.mkFirst (First.lhs:37:11-27) First.mkFirst (First.lhs:37:11-93) Main.main2.runParserGen.first (Main.lhs:107:48-56) Main.main2.runParserGen.first (Main.lhs:107:27-57) Main.main2.runParserGen (Main.lhs:(96,9)-(276,9)) Main.main2.runParserGen (Main.lhs:(90,9)-(276,10)) Main.main2.runParserGen (Main.lhs:(86,9)-(276,10)) Main.main2.runParserGen (Main.lhs:(85,9)-(276,10)) Main.main2 (Main.lhs:74:20-43) Main.main2 (Main.lhs:(64,9)-(78,61)) Main.main (Main.lhs:57:9-18) ``` Test Plan: validate Reviewers: erikd, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1765 GHC Trac Issues: #11047
* Rework the Implicit CallStack solver to handle local lets.Eric Seidel2015-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can't just solve CallStack constraints indiscriminately when they occur in the RHS of a let-binder. The top-level given CallStack (if any) will not be in scope, so I've re-worked the CallStack solver as follows: 1. CallStacks are treated like regular IPs unless one of the following two rules apply. 2. In a function call, we push the call-site onto a NEW wanted CallStack, which GHC will solve as a regular IP (either directly from a given, or by quantifying over it in a local let). 3. If, after the constraint solver is done, any wanted CallStacks remain, we default them to the empty CallStack. This rule exists mainly to clean up after rule 2 in a top-level binder with no given CallStack. In rule (2) we have to be careful to emit the new wanted with an IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire again. This is a bit shady but I've updated the Note to explain the trick. Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1422 GHC Trac Issues: #10845
* base: export allocation counter/limit API from System.MemSimon Marlow2015-09-231-2/+2
| | | | | | | | | | | Previously it was only available from GHC.Conc, but it makes sense for it to be available from a more official place where people might find it. While I was here, I improved the docs a little. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1272
* Use IP based CallStack in error and undefinedEric Seidel2015-09-021-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch modifies `error`, `undefined`, and `assertError` to use implicit call-stacks to provide better error messages to users. There are a few knock-on effects: - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in types for `error` and `undefined`. - `TysPrim.tyVarList` has been replaced with a new function `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce subtle bugs when you need tyvars of different kinds. The naive ``` tv1 = head $ tyVarList kind1 tv2 = head $ tyVarList kind2 ``` would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions would be applied incorrectly, treating `tv1` and `tv2` as the same tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds and producing a single tyvar of each kind. - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in ghc-prim. - The type `GHC.Exception.ErrorCall` has a new constructor `ErrorCallWithLocation` that takes two `String`s instead of one, the 2nd one being arbitrary metadata about the error (but usually the call-stack). A bi-directional pattern synonym `ErrorCall` continues to provide the old API. Updates Cabal, array, and haddock submodules. Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter, liyang, bgamari, thomie Differential Revision: https://phabricator.haskell.org/D861 GHC Trac Issues: #5273
* Make Exception datatypes into newtypesRyanGlScott2015-08-051-1/+1
| | | | | | | | | | | | | | | Certain instances of `Exception` are simply datatypes with only one argument, which should be `newtype`s. Reviewers: ekmett, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1131 GHC Trac Issues: #10738
* Derive Generic instance for System.Exit.ExitCodeHerbert Valerio Riedel2015-04-141-2/+3
| | | | | | Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D830
* base: drop redundant Typeable derivingsHerbert Valerio Riedel2015-03-071-12/+5
| | | | | | | | | | | Thanks to #9858 `Typeable` doesn't need to be explicitly derived anymore. This also makes `AutoDeriveTypeable` redundant, as well as some imports of `Typeable` (removal of whose may be beneficial to #9707). This commit removes several such now redundant use-sites in `base`. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D712
* AllocationLimitExceeded should be a child of SomeAsyncExceptionSimon Marlow2015-02-261-1/+3
|
* System.IO.Error: Fix a documentation link to Control.Exception.ExceptionWieland Hoffmann2015-02-231-1/+1
| | | | | | | | Instead of using double quotes (which are used to link to modules), use single quotes (that are used to link, among others, to link to types, which C.E.Exception is). Signed-off-by: Austin Seipp <austin@well-typed.com>
* Fix typo in error messageGabor Greif2015-02-171-1/+1
|
* Convert `/Since: .../` to new `@since ...` syntaxHerbert Valerio Riedel2014-12-161-4/+4
| | | | | | Starting with Haddock 2.16 there's a new built-in support for since-annotations Note: This exposes a bug in the `@since` implementation (see e.g. `Data.Bits`)
* Changelog entry and /Since/ for alloc-counter opsHerbert Valerio Riedel2014-11-241-0/+2
| | | | | | See b0534f78a73f972e279eed4447a5687bd6a8308e for more details [skip ci]
* Per-thread allocation counters and limitsSimon Marlow2014-11-121-1/+20
| | | | | | | | This reverts commit f0fcc41d755876a1b02d1c7c79f57515059f6417. New changes: now works on 32-bit platforms too. I added some basic support for 64-bit subtraction and comparison operations to the x86 NCG.
* Move `Maybe`-typedef into GHC.BaseHerbert Valerio Riedel2014-09-161-1/+0
| | | | | | | This is preparatory work for reintroducing SPECIALISEs that were lost in d94de87252d0fe2ae97341d186b03a2fbe136b04 Differential Revision: https://phabricator.haskell.org/D214
* Replace DeriveDataTypeable by AutoDeriveTypeableHerbert Valerio Riedel2014-05-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a first step towards addressing #9111 This results in the following additional Typeable (exported) instances being generated (list was compiled by diff'ing hoogle txt output): instance Typeable CFile instance Typeable 'CFile instance Typeable CFpos instance Typeable 'CFpos instance Typeable CJmpBuf instance Typeable 'CJmpBuf instance Typeable ChItem instance Typeable QSem instance Typeable ID instance Typeable 'ID instance Typeable CONST instance Typeable Qi instance Typeable Qr instance Typeable Mp instance Typeable ConstrRep instance Typeable Fixity instance Typeable 'Prefix instance Typeable 'Infix instance Typeable Constr instance Typeable DataType instance Typeable DataRep instance Typeable Data instance Typeable HasResolution instance Typeable IsList Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Revert "Per-thread allocation counters and limits"Simon Marlow2014-05-041-20/+1
| | | | | | | | Problems were found on 32-bit platforms, I'll commit again when I have a fix. This reverts the following commits: 54b31f744848da872c7c6366dea840748e01b5cf b0534f78a73f972e279eed4447a5687bd6a8308e
* Per-thread allocation counters and limitsSimon Marlow2014-05-021-1/+20
| | | | | | | | | | | | | | | | | | | | | | | This tracks the amount of memory allocation by each thread in a counter stored in the TSO. Optionally, when the counter drops below zero (it counts down), the thread can be sent an asynchronous exception: AllocationLimitExceeded. When this happens, given a small additional limit so that it can handle the exception. See documentation in GHC.Conc for more details. Allocation limits are similar to timeouts, but - timeouts use real time, not CPU time. Allocation limits do not count anything while the thread is blocked or in foreign code. - timeouts don't re-trigger if the thread catches the exception, allocation limits do. - timeouts can catch non-allocating loops, if you use -fno-omit-yields. This doesn't work for allocation limits. I couldn't measure any impact on benchmarks with these changes, even for nofib/smp.
* Minor fixes to Haddock markupHerbert Valerio Riedel2014-02-211-2/+2
| | | | Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Add Haddock `/Since: 4.7.0.0/` comments to new symbolsHerbert Valerio Riedel2013-09-211-0/+5
| | | | | | | | | | | | | | | | | | These annotations were added in such a way, that the line {{{ /Since: 4.7.0.0/ }}} represents the last paragraph of the Haddock comment. Maybe Haddock will have support for this meta-syntax at some point, and be able to inherited the since-version property to the children of an annotated symbol and display the since-version property in the rendered documentation only in cases when it's not visually obvious (for instance, when re-exporting documentation strings). Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Follow changes in comparison primops (see #6135)Jan Stolarek2013-09-181-2/+2
|
* Trailing whitespacesJan Stolarek2013-09-181-7/+7
|
* Make a class for asynchronous exceptions in the exception hierarchySimon Marlow2012-12-101-3/+27
| | | | | | | | | | | | | | | | | | | | | | Right now, we only have data AsyncException = StackOverflow | HeapOverflow | ThreadKilled | ... so it is not possible to add another async exception. For instance, the Timeout exception in System.Timeout should really be an async exception. This patch adds a superclass for all async exceptions: data SomeAsyncException = forall e . Exception e => SomeAsyncException e deriving Typeable and makes the existing AsyncException and Timeout children of SomeAsyncException in the hierarchy.
* Update some H98 references to refer to H2010Ian Lynagh2012-11-171-3/+3
|
* Update base for latest Safe Haskell.David Terei2011-10-251-0/+2
|
* If an assertion fails, through it rather than a deeper error; fixes #5561Ian Lynagh2011-10-191-1/+4
| | | | | | An expression like assert False (throw e) should throw the assertion failure rather than e
* SafeHaskell: Added SafeHaskell to baseDavid Terei2011-06-181-0/+1
|
* Use explicit language extensions & remove extension fields from base.cabalsimonpj@microsoft.com2011-01-281-1/+2
| | | | | | | | | | Add explicit {-# LANGUAGE xxx #-} pragmas to each module, that say what extensions that module uses. This makes it clearer where different extensions are used in the (large, variagated) base package. Now base.cabal doesn't need any extensions field Thanks to Bas van Dijk for doing all the work.
* add doc for the ExitCode typeSimon Marlow2010-06-221-0/+1
|
* Correct haddock formatting.Adam Vogt2010-04-231-1/+1
|
* Tweak docsIan Lynagh2010-03-121-1/+1
|
* Documentation fixes in Control.ExceptionBas van Dijk2010-03-011-3/+2
|
* Address #3310Simon Marlow2009-08-301-14/+14
| | | | | | | | | | | | | | - Rename BlockedOnDeadMVar -> BlockedIndefinitelyOnMVar - Rename BlockedIndefinitely -> BlockedIndefinitelyOnSTM - instance Show BlockedIndefinitelyOnMVar is now "blocked indefinitely in an MVar operation" - instance Show BlockedIndefinitelyOnSTM is now "blocked indefinitely in an STM transaction" clients using Control.OldException will be unaffected (the new exceptions are mapped to the old names). However, for base4-compat we'll need to make a version of catch/try that does a similar mapping.
* warning fix: -fno-implicit-prelude -> -XNoImplicitPreludeSimon Marlow2009-07-151-1/+1
|
* Rewrite of the IO library, including Unicode supportSimon Marlow2009-06-121-0/+336
Highlights: * Unicode support for Handle I/O: ** Automatic encoding and decoding using a per-Handle encoding. ** The encoding defaults to the locale encoding (only on Unix so far, perhaps Windows later). ** Built-in UTF-8, UTF-16 (BE/LE), and UTF-32 (BE/LE) codecs. ** iconv-based codec for other encodings on Unix * Modularity: the low-level IO interface is exposed as a type class (GHC.IO.IODevice) so you can build your own low-level IO providers and make Handles from them. * Newline translation: instead of being Windows-specific wired-in magic, the translation from \r\n -> \n and back again is available on all platforms and is configurable for reading/writing independently. Unicode-aware Handles ~~~~~~~~~~~~~~~~~~~~~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing locale encoding of the system (except on Windows [1]). Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: GHC.IO.Handle.hSetEncoding :: Handle -> TextEncoding -> IO () and various encodings (from GHC.IO.Encoding): latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: GHC.IO.Encoding.mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). We may want to export these from somewhere more permanent; that's a topic for a future library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance varies. For "hGetContents >>= putStr" I found the new library was faster on my x86_64 machine, but slower on an x86. On the whole I'd expect things to be a bit slower due to the extra decoding/encoding, but probabaly not noticeably. If performance is critical for your app, then you should be using bytestring and text anyway. [1] Note: locale encoding is not currently implemented on Windows due to the built-in Win32 APIs for encoding/decoding not being sufficient for our purposes. Ask me for details. Offers of help gratefully accepted. Newline Translation ~~~~~~~~~~~~~~~~~~~ In the old IO library, text-mode Handles on Windows had automatic translation from \r\n -> \n on input, and the opposite on output. It was implemented using the underlying CRT functions, which meant that there were certain odd restrictions, such as read/write text handles needing to be unbuffered, and seeking not working at all on text Handles. In the rewrite, newline translation is now implemented in the upper layers, as it needs to be since we have to perform Unicode decoding before newline translation. This means that it is now available on all platforms, which can be quite handy for writing portable code. For now, I have left the behaviour as it was, namely \r\n -> \n on Windows, and no translation on Unix. However, another reasonable default (similar to what Python does) would be to do \r\n -> \n on input, and convert to the platform-native representation (either \r\n or \n) on output. This is called universalNewlineMode (below). The API is as follows. (available from GHC.IO.Handle for now, again this is something we will probably want to try to get into System.IO at some point): -- | The representation of a newline in the external file or stream. data Newline = LF -- ^ "\n" | CRLF -- ^ "\r\n" deriving Eq -- | Specifies the translation, if any, of newline characters between -- internal Strings and the external file or stream. Haskell Strings -- are assumed to represent newlines with the '\n' character; the -- newline mode specifies how to translate '\n' on output, and what to -- translate into '\n' on input. data NewlineMode = NewlineMode { inputNL :: Newline, -- ^ the representation of newlines on input outputNL :: Newline -- ^ the representation of newlines on output } deriving Eq -- | The native newline representation for the current platform nativeNewline :: Newline -- | Map "\r\n" into "\n" on input, and "\n" to the native newline -- represetnation on output. This mode can be used on any platform, and -- works with text files using any newline convention. The downside is -- that @readFile a >>= writeFile b@ might yield a different file. universalNewlineMode :: NewlineMode universalNewlineMode = NewlineMode { inputNL = CRLF, outputNL = nativeNewline } -- | Use the native newline representation on both input and output nativeNewlineMode :: NewlineMode nativeNewlineMode = NewlineMode { inputNL = nativeNewline, outputNL = nativeNewline } -- | Do no newline translation at all. noNewlineTranslation :: NewlineMode noNewlineTranslation = NewlineMode { inputNL = LF, outputNL = LF } -- | Change the newline translation mode on the Handle. hSetNewlineMode :: Handle -> NewlineMode -> IO () IO Devices ~~~~~~~~~~ The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) => dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' -> FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. -> IOMode -- ^ The mode in which the 'Handle' is to be used -> Maybe TextEncoding -- ^ text encoding to use, if any -> NewlineMode -- ^ newline translation mode -> IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding and newline translation). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated warnings. I split modules into smaller parts in many places. For example, we now have GHC.IORef, GHC.MVar and GHC.IOArray containing the implementations of IORef, MVar and IOArray respectively. This was necessary for untangling dependencies, but it also makes things easier to follow. The new module structurue for the IO-relatied parts of the base package is: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv GHC.IO.Encoding.Latin1 GHC.IO.Encoding.UTF8 GHC.IO.Encoding.UTF16 GHC.IO.Encoding.UTF32 Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc.
View Lorry Controller Status