summaryrefslogtreecommitdiff
path: root/libraries/base/Prelude.hs
Commit message (Collapse)AuthorAgeFilesLines
* compiler: Qualify imports of Data.ListBen Gamari2020-02-081-12/+20
|
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-03-221-1/+2
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Reexport Semigroup's <> operator from Prelude (#14191)Herbert Valerio Riedel2017-09-221-1/+1
| | | | | | | This completes the 2nd phase of the Semigroup=>Monoid Proposal (SMP) initiated in 8ae263ceb3566a7c82336400b09cb8f381217405. This updates a couple submodules to address <> naming clashes.
* Make Semigroup a superclass of Monoid (re #14191)Herbert Valerio Riedel2017-09-071-1/+2
| | | | | | | | | | | | | | | | | | | Unfortunately, this requires introducing a couple of .hs-boot files to break up import cycles (mostly to provide class & typenames in order to be able to write type signatures). This does not yet re-export `(<>)` from Prelude (while the class-name `Semigroup` is reexported); that will happen in a future commit. Test Plan: local ./validate passed Reviewers: ekmett, austin, bgamari, erikd, RyanGlScott Reviewed By: ekmett, RyanGlScott GHC Trac Issues: #14191 Differential Revision: https://phabricator.haskell.org/D3927
* Allow CallStacks to be frozenEric Seidel2015-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces "freezing," an operation which prevents further locations from being appended to a CallStack. Library authors may want to prevent CallStacks from exposing implementation details, as a matter of hygiene. For example, in ``` head [] = error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` including the call-site of `error` in `head` is not strictly necessary as the error message already specifies clearly where the error came from. So we add a function `freezeCallStack` that wraps an existing CallStack, preventing further call-sites from being pushed onto it. In other words, ``` pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack ``` Now we can define `head` to not produce a CallStack at all ``` head [] = let ?callStack = freezeCallStack emptyCallStack in error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` --- 1. We add the `freezeCallStack` and `emptyCallStack` and update the definition of `CallStack` to support this functionality. 2. We add `errorWithoutStackTrace`, a variant of `error` that does not produce a stack trace, using this feature. I think this is a sensible wrapper function to provide in case users want it. 3. We replace uses of `error` in base with `errorWithoutStackTrace`. The rationale is that base does not export any functions that use CallStacks (except for `error` and `undefined`) so there's no way for the stack traces (from Implicit CallStacks) to include user-defined functions. They'll only contain the call to `error` itself. As base already has a good habit of providing useful error messages that name the triggering function, the stack trace really just adds noise to the error. (I don't have a strong opinion on whether we should include this third commit, but the change was very mechanical so I thought I'd include it anyway in case there's interest) 4. Updates tests in `array` and `stm` submodules Test Plan: ./validate, new test is T11049 Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari Reviewed By: simonpj Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1628 GHC Trac Issues: #11049
* Re-export `<$` from Prelude (#10113)Herbert Valerio Riedel2015-03-071-1/+1
| | | | | | | | | This is a follow-up to eb3661f2b9f8472f3714774126ebe1183484dd85 re-exporting `<$` from `Prelude` as well. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D681
* Re-export `<$>` from Prelude (#10113)Herbert Valerio Riedel2015-03-071-1/+2
| | | | | | | | | | | | | | | | | | | | | Whether to re-export the `<$>` non-method operator from `Prelude` wasn't explicitly covered in the original AMP proposal[1], but it turns out that not doing so forces most code that makes use of applicatives to import `Data.Functor` or `Control.Applicative` just to get that operator into scope. To this end, it was proposed to add `<$>` to Prelude as well[2]. The down-side is that this increases the amount of redundant-import warnings triggered, as well as the relatively minor issue of stealing the `<$>` operator from the default namespace for good (although at this point `<$>` is supposed to be ubiquitous anyway due to `Applicative` being implicitly required into the next Haskell Report) [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal [2]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D680
* Drop redundant LANGUAGE pragmasHerbert Valerio Riedel2015-03-071-1/+1
| | | | Due to refactoring & cleanups those pragmas have become redundant by now
* Export `Monoid(..)`/`Foldable(..)`/`Traversable(..)` from PreludeHerbert Valerio Riedel2014-09-211-11/+25
| | | | | | | | | | | | | | | This finally exposes also the methods of these 3 classes in the Prelude in order to allow to define basic class instances w/o needing imports. This almost completes the primary goal of #9586 NOTE: `fold`, `foldl'`, `foldr'`, and `toList` are not exposed yet, as they require upstream fixes for at least `containers` and `bytestring`, and are not required for defining basic instances. Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D236
* Move `mapM` and `sequence` to GHC.Base and break import-cyclesHerbert Valerio Riedel2014-09-211-1/+1
| | | | | | | | | | This simplifies the import graph and more importantly removes import cycles that arise due to `Control.Monad` & `Data.List` importing `Data.Traversable` (preparation for #9586) Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D234
* Set up framework for generalising Data.List to FoldablesHerbert Valerio Riedel2014-09-201-1/+1
| | | | | | | | | | | | | | | | | | | | | This renames the Data.List module to Data.OldList, and puts a new Data.List module into its place re-exporting all list functions. The plan is to leave the monomorphic versions of the list functions in Data.OldList to help smooth the transition. The new Data.List module then will simply re-export entities from Data.OldList and Data.Foldable. This refactoring has been placed in a separate commit to be able to better isolate any regressions caused by the actual list function generalisations when implementing #9586 This also updates the haskell2010, haskell98, and array submodules Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D228
* Export `Traversable()` and `Foldable()` from PreludeHerbert Valerio Riedel2014-09-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | This exposes *only* the type-classes w/o any of their methods. This is the very first step for implementing BPP (see #9586), which already requires breaking up several import-cycles leading back to `Prelude`. Ideally, importing `Prelude` should be avoided in most `base` modules, as `Prelude` does not define any entities, but rather re-exports existing ones. Test Plan: validate passes Reviewers: ekmett, austin Reviewed By: ekmett, austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D209 GHC Trac Issues: #9586
* Move docstring of `seq` to primops.txt.ppHerbert Valerio Riedel2014-09-131-16/+0
| | | | | | | | | | | The documentation for `seq` was recently augmented via #9390 & cbfa107604f4cbfaf02bd633c1faa6ecb90c6dd7. However, it doesn't show up in the Haddock generated docs because `#ifdef __HADDOCK__` doesn't work as expected. Also, it's easier to just fix the problem at the origin (which in this is case is the primops.txt.pp file). The benefit/downside of this is that now the extended documentation shows up everywhere `seq` is re-exported directly.
* Move ($!) from Prelude into GHC.BaseHerbert Valerio Riedel2014-09-131-8/+0
| | | | | | | | | I don't see any reason why this needs to be in Prelude, where it makes life harder to avoid import cycles involving Prelude. Ideally, the `Prelude` module should only re-export entities from other modules, and not define anything on its own. So this moves `($!)` close to the definition of its `($)` cousin.
* Make Applicative a superclass of MonadAustin Seipp2014-09-091-1/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This includes pretty much all the changes needed to make `Applicative` a superclass of `Monad` finally. There's mostly reshuffling in the interests of avoid orphans and boot files, but luckily we can resolve all of them, pretty much. The only catch was that Alternative/MonadPlus also had to go into Prelude to avoid this. As a result, we must update the hsc2hs and haddock submodules. Signed-off-by: Austin Seipp <austin@well-typed.com> Test Plan: Build things, they might not explode horribly. Reviewers: hvr, simonmar Subscribers: simonmar Differential Revision: https://phabricator.haskell.org/D13
* `M-x delete-trailing-whitespace` & `M-x untabify`...Herbert Valerio Riedel2014-08-311-1/+1
| | | | | | ...some files more or less recently touched by me [ci skip]
* Re-export Word from Prelude (re #9531)Herbert Valerio Riedel2014-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original proposal text can be found at http://www.haskell.org/pipermail/libraries/2014-August/023491.html The proposal passed with a clear majority, and was additionally confirmed by the core libraries committee. *Compatibility Note* Only code that imports `Data.Word` for the sole purpose of using `Word` *and* requires to be `-Werror`-clean (due to `-fwarn-unused-imports`) is affected by this change. In order to write warning-free forward/backward compatible against `base`, a variant of the following CPP-based snippet can be used: -- Starting with base>4.7.0 or GHC>7.8 Prelude re-exports 'Word' -- The following is needed, if 'Word' is the *only* entity needed from Data.Word #ifdef MIN_VERSION_base # if !MIN_VERSION_base(4,7,1) import Data.Word (Word) # endif -- no cabal_macros.h -- fallback to __GLASGOW_HASKELL__ #elif __GLASGOW_HASKELL__ < 709 import Data.Word (Word) #endif This also updates the haddock submodule in order to avoid a compile warning
* Improve seq documentation; part of trac issue #9390Michael Snoyman2014-08-101-0/+7
| | | | | | | | | | | | | | | | Summary: Signed-off-by: Michael Snoyman <michael@snoyman.com> Test Plan: Review documentation change Reviewers: simonpj, austin Reviewed By: austin Subscribers: phaskell, hvr, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D136 GHC Trac Issues: #9390
* Constant-fold `__GLASGOW_HASKELL__` CPP conditionalsHerbert Valerio Riedel2013-09-171-6/+0
| | | | | | | | | | Now that HUGS and NHC specific code has been removed, this commit "folds" the now redundant `#if((n)def)`s containing `__GLASGOW_HASKELL__`. This renders `base` officially GHC only. This commit also removes redundant `{-# LANGUAGE CPP #-}`. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Remove Hugs98 specific codeHerbert Valerio Riedel2013-09-171-13/+1
| | | | | | | For rationale. see http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2349 Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Fix import warningsIan Lynagh2013-06-061-1/+0
|
* Remove nhc98-specific files and contentIan Lynagh2013-02-151-7/+0
|
* Improve the Prelude doc header; part of #7108Ian Lynagh2012-11-171-3/+3
| | | | | | | | It no longer refers to a particular version of the language standard. It now includes a note about how it is implicitly imported, and it looks like the other documentation from the language report is already included in the haddock docs.
* Refer and link to Haskell 2010 report in Prelude.Paolo Capriotti2012-08-081-2/+2
|
* Remove Prelude.catch and System.IO.Error.{catch,try}Ian Lynagh2012-06-191-1/+1
| | | | This completes the proposal from trac #4865.
* SafeHaskell: Added SafeHaskell to baseDavid Terei2011-06-181-2/+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.
* Use let !y = x in .. x .. instead of seq in $! and evaluate (#2273)Simon Marlow2009-09-161-1/+5
|
* Remove unused imports from basesimonpj@microsoft.com2009-07-061-3/+3
| | | | | These unused imports are detected by the new unused-import code
* Rewrite of the IO library, including Unicode supportSimon Marlow2009-06-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Move some catch definitions around to avoid an import loopIan Lynagh2009-01-141-27/+1
| | | | As suggested by simonpj in trac #2822.
* Fix some more warningsIan Lynagh2008-08-201-1/+0
|
* simplify definition of Prelude.catchRoss Paterson2008-08-141-5/+6
|
* Fix a couple of importsIan Lynagh2008-08-061-1/+1
|
* Remove unused importsIan Lynagh2008-08-011-7/+2
|
* Start to actually use extensible exceptionsIan Lynagh2008-07-301-0/+26
|
* Avoid using deprecated flagsIan Lynagh2008-06-161-1/+1
|
* untabifyDon Stewart2008-03-031-11/+11
|
* Remove IsString(fromString) from the PreludeIan Lynagh2007-01-301-5/+0
|
* IsString is GHC-only (so why is it in the Prelude?)Ross Paterson2007-01-231-0/+2
|
* Add IsString class for overloaded string literals.lennart@augustsson.net2006-12-211-0/+3
|
* [project @ 2005-03-14 17:23:22 by ross]ross2005-03-141-3/+2
| | | | Hugs only: don't import Data.{Eq,Ord}
* [project @ 2005-03-14 15:46:12 by simonmar]simonmar2005-03-141-1/+3
| | | | | Add Data.Ord and Data.Eq. Data.Ord also exports the new function 'comparing', as discussed on the libraries list a while back.
* [project @ 2005-01-11 16:04:08 by simonmar]simonmar2005-01-111-1/+1
| | | | Use OPTIONS_GHC instead of OPTIONS
* [project @ 2004-07-26 17:22:41 by ross]ross2004-07-261-0/+8
| | | | a few odd docs
* [project @ 2004-07-26 13:26:41 by ross]ross2004-07-261-4/+8
| | | | docs only
* [project @ 2003-11-26 09:55:22 by simonmar]simonmar2003-11-261-1/+1
| | | | Declare some libraries to be "stable".
* [project @ 2003-09-05 15:06:48 by ross]ross2003-09-051-1/+1
| | | | doc tweaks
* [project @ 2003-09-01 09:12:02 by ross]ross2003-09-011-28/+56
| | | | H98 docs for Data.List
* [project @ 2003-08-30 12:26:56 by ross]ross2003-08-301-3/+13
| | | | docs for System.IO.Error
View Lorry Controller Status