1. 15 Feb, 2013 1 commit
  2. 10 Dec, 2012 1 commit
    • Simon Marlow's avatar
      Make a class for asynchronous exceptions in the exception hierarchy · 756a970e
      Simon Marlow authored
      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.
      756a970e
  3. 17 Nov, 2012 1 commit
  4. 19 Oct, 2012 1 commit
  5. 18 Oct, 2011 1 commit
  6. 18 Jun, 2011 1 commit
  7. 14 May, 2011 1 commit
    • batterseapower's avatar
      Big patch to improve Unicode support in GHC. Validated on OS X and Windows, this · dc58b739
      batterseapower authored
      patch series fixes #5061, #1414, #3309, #3308, #3307, #4006 and #4855.
      
      The major changes are:
      
       1) Make Foreign.C.String.*CString use the locale encoding
      
          This change follows the FFI specification in Haskell 98, which
          has never actually been implemented before.
      
          The functions exported from Foreign.C.String are partially-applied
          versions of those from GHC.Foreign, which allows the user to supply
          their own TextEncoding.
      
          We also introduce foreignEncoding as the name of the text encoding
          that follows the FFI appendix in that it transliterates encoding
          errors.
      
       2) I also changed the code so that mkTextEncoding always tries the
          native-Haskell decoders in preference to those from iconv, even on
          non-Windows. The motivation here is simply that it is better for
          compatibility if we do this, and those are the ones you get for
          the utf* and latin1* predefined TextEncodings anyway.
      
       3) Implement surrogate-byte error handling mode for TextEncoding
      
          This implements PEP383-like behaviour so that we are able to
          roundtrip byte strings through Strings without loss of information.
      
          The withFilePath function now uses this encoding to get to/from CStrings,
          so any code that uses that will get the right PEP383 behaviour automatically.
      
       4) Implement three other coding failure modes: ignore, throw error, transliterate
      
          These mimic the behaviour of the GNU Iconv extensions.
      dc58b739
  8. 24 Apr, 2011 1 commit
  9. 28 Jan, 2011 1 commit
  10. 24 Sep, 2010 1 commit
  11. 14 Sep, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Add absentError. · c3c5bee6
      simonpj@microsoft.com authored
      This patch accompanies the HEAD patch:
      
        Tue Sep 14 12:38:27 BST 2010  simonpj@microsoft.com
          * Make absent-arg wrappers work for unlifted types (fix Trac #4306)
          
          Previously we were simply passing arguments of unlifted
          type to a wrapper, even if they were absent, which was
          stupid.
          
          See Note [Absent error Id] in WwLib.
      c3c5bee6
  12. 10 Aug, 2010 1 commit
  13. 10 Jul, 2010 1 commit
  14. 08 Jul, 2010 1 commit
    • Simon Marlow's avatar
      New asynchronous exception control API (base parts) · 73157075
      Simon Marlow authored
        
      As discussed on the libraries/haskell-cafe mailing lists
        http://www.haskell.org/pipermail/libraries/2010-April/013420.html
      
      This is a replacement for block/unblock in the asychronous exceptions
      API to fix a problem whereby a function could unblock asynchronous
      exceptions even if called within a blocked context.
      
      The new terminology is "mask" rather than "block" (to avoid confusion
      due to overloaded meanings of the latter).
      
      The following is the new API; the old API is deprecated but still
      available for the time being.
      
      Control.Exception
      -----------------
      
      mask  :: ((forall a. IO a -> IO a) -> IO b) -> IO b
      mask_ :: IO a -> IO a
      
      uninterruptibleMask :: ((forall a. IO a -> IO a) -> IO b) -> IO b
      uninterruptibleMask_ :: IO a -> IO 
      
      getMaskingState :: IO MaskingState
      
      data MaskingState
        = Unmasked
        | MaskedInterruptible 
        | MaskedUninterruptible
      
      
      Control.Concurrent
      ------------------
      
      forkIOUnmasked :: IO () -> IO ThreadId
      73157075
  15. 12 Mar, 2010 1 commit
  16. 01 Mar, 2010 1 commit
  17. 23 Nov, 2009 1 commit
  18. 09 Oct, 2009 1 commit
  19. 30 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Address #3310 · a5e2fa98
      Simon Marlow authored
       - 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.
      a5e2fa98
  20. 21 Jul, 2009 1 commit
  21. 10 Jul, 2009 1 commit
  22. 06 Jul, 2009 1 commit
  23. 12 Jun, 2009 1 commit
    • Simon Marlow's avatar
      Rewrite of the IO library, including Unicode support · 7b067f2d
      Simon Marlow authored
      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.
      7b067f2d
  24. 31 Jan, 2009 1 commit
  25. 16 Jan, 2009 1 commit
  26. 02 Jan, 2009 1 commit
  27. 20 Aug, 2008 1 commit
  28. 12 Aug, 2008 1 commit
    • Ross Paterson's avatar
      split most of Control.Exception into new Control.Exception.Base · ec16083b
      Ross Paterson authored
      Move everything but catches/Handler into a new internal module.
      This was needed to get the new exceptions working with Hugs, because Hugs
      has the constraint that all Haskell 98 library modules, and everything
      they include, must be Haskell 98.  This also involves a different
      representation of SomeException for Hugs, so that type is exported
      opaquely for Hugs.  Then Control.Exception.Base is Haskell 98 as far as
      Hugs is concerned, but Control.Exception needs the extensions turned on.
      
      Control.Exception re-exports everything from Control.Exception.Base
      except the functions used by the GHC runtime.
      ec16083b
  29. 04 Aug, 2008 2 commits
  30. 05 Aug, 2008 1 commit
  31. 04 Aug, 2008 1 commit
  32. 03 Aug, 2008 3 commits
  33. 02 Aug, 2008 1 commit
    • Ian Lynagh's avatar
      Remove the dangerous Exception functions · ed6aac28
      Ian Lynagh authored
      Removed: catchAny, handleAny, ignoreExceptions
      These make it easy to eat /any/ exception, which is rarely what you want.
      Normally you either want to:
      * only catch exceptions in a certain part of the hierarchy, e.g.
        "file not found", in which case you should only catch exceptions
        of the appropriate type,
      or
      * you want to do some cleanup when an exception happens, and then rethrow
        the exception, in which case you should use onException, or one of the
        bracketing functions.
      ed6aac28
  34. 01 Aug, 2008 3 commits
  35. 30 Jul, 2008 1 commit