Gets the contents of a file, but guarantee that it gets closed.

The file is read lazily but if it is not fully consumed by the action then the remaining input is truncated and the file is closed.

Writes a file atomically.

The file is either written successfully or an IO exception is raised and the original file is left unchanged.

On windows it is not possible to delete a file that is open by a process. This case will give an IO exception but the atomic property is not affected.

Decode String from UTF8-encoded ByteString

Invalid data in the UTF8 stream (this includes code-points U+D800 through U+DFFF) will be decoded as the replacement character (U+FFFD).

Variant of fromUTF8BS for lazy ByteStrings

Encode String to UTF8-encoded ByteString

Code-points in the U+D800-U+DFFF range will be encoded as the replacement character (i.e. U+FFFD).

Variant of toUTF8BS for lazy ByteStrings

Check that strict ByteString is valid UTF8. Returns 'Just offset' if it's not.

Reads a UTF8 encoded text file as a Unicode String

Reads lazily using ordinary readFile.

Reads a UTF8 encoded text file as a Unicode String

Same behaviour as withFileContents.

Writes a Unicode String as a UTF8 encoded text file.

Uses writeFileAtomic, so provides the same guarantees.

Ignore a Unicode byte order mark (BOM) at the beginning of the input

Fix different systems silly line ending conventions

dropWhileEndLE p is equivalent to reverse . dropWhile p . reverse, but quite a bit faster. The difference between "Data.List.dropWhileEnd" and this version is that the one in Data.List is strict in elements, but spine-lazy, while this one is spine-strict but lazy in elements. That's what LE stands for - "lazy in elements".

Example:

>>> safeTail $ Data.List.dropWhileEnd (<3) [undefined, 5, 4, 3, 2, 1]
*** Exception: Prelude.undefined
...

>>> safeTail $ dropWhileEndLE (<3) [undefined, 5, 4, 3, 2, 1]
[5,4,3]

>>> take 3 $ Data.List.dropWhileEnd (<3) [5, 4, 3, 2, 1, undefined]
[5,4,3]

>>> take 3 $ dropWhileEndLE (<3) [5, 4, 3, 2, 1, undefined]
*** Exception: Prelude.undefined
...

takeWhileEndLE p is equivalent to reverse . takeWhile p . reverse, but is usually faster (as well as being easier to read).

comparing p x y = compare (p x) (p y)

Useful combinator for use in conjunction with the xxxBy family of functions from Data.List, for example:

  ... sortBy (comparing fst) ...

The isInfixOf function takes two lists and returns True iff the first list is contained, wholly and intact, anywhere within the second.

>>> isInfixOf "Haskell" "I really like Haskell."
True

>>> isInfixOf "Ial" "I really like Haskell."
False

intercalate xs xss is equivalent to (concat (intersperse xs xss)). It inserts the list xs in between the lists in xss and concatenates the result.

>>> intercalate ", " ["Lorem", "ipsum", "dolor"]
"Lorem, ipsum, dolor"

Lower case string

>>> lowercase "Foobar"
"foobar"

Ascii characters

Ascii letters.

Ascii letters and digits.

>>> isAsciiAlphaNum 'a'
True

>>> isAsciiAlphaNum 'ä'
False

Like "Data.List.union", but has O(n log n) complexity instead of O(n^2).

A right-biased version of listUnion.

Example:

>>> listUnion [1,2,3,4,3] [2,1,1]
[1,2,3,4,3]

>>> listUnionRight [1,2,3,4,3] [2,1,1]
[4,3,2,1,1]

Like nub, but has O(n log n) complexity instead of O(n^2). Code for ordNub and listUnion taken from Niklas Hambüchen's ordnub package.

Like ordNub and nubBy. Selects a key for each element and takes the nub based on that key.

A right-biased version of ordNub.

Example:

>>> ordNub [1,2,1] :: [Int]
[1,2]

>>> ordNubRight [1,2,1] :: [Int]
[2,1]

A total variant of head.

Since: Cabal-3.2.0.0

A total variant of tail.

Since: Cabal-3.2.0.0

A total variant of last.

Since: Cabal-3.2.0.0

A total variant of init.

Since: Cabal-3.2.0.0

Wraps text to the default line width. Existing newlines are preserved.

Wraps a list of words to a list of lines of words of a particular width.

unfoldr with monadic action.

>>> take 5 $ unfoldrM (\b r -> Just (r + b, b + 1)) (1 :: Int) 2
[3,4,5,6,7]

Since: Cabal-2.2

Like span but with Maybe predicate

>>> spanMaybe listToMaybe [[1,2],[3],[],[4,5],[6,7]]
([1,3],[[],[4,5],[6,7]])

>>> spanMaybe (readMaybe :: String -> Maybe Int) ["1", "2", "foo"]
([1,2],["foo"])

Since: Cabal-2.2

Like break, but with Maybe predicate

>>> breakMaybe (readMaybe :: String -> Maybe Int) ["foo", "bar", "1", "2", "quu"]
(["foo","bar"],Just (1,["2","quu"]))

>>> breakMaybe (readMaybe :: String -> Maybe Int) ["foo", "bar"]
(["foo","bar"],Nothing)

Since: Cabal-2.2

The opposite of snoc, which is the reverse of cons

Example:

>>> unsnoc [1, 2, 3]
Just ([1,2],3)

>>> unsnoc []
Nothing

Since: Cabal-3.2.0.0

Like unsnoc, but for NonEmpty so without the Maybe

Example:

>>> unsnocNE (1 :| [2, 3])
([1,2],3)

>>> unsnocNE (1 :| [])
([],1)

Since: Cabal-3.2.0.0

Since: Cabal-3.4.0.0

Since: Cabal-3.4.0.0

Since: Cabal-3.4.0.0

isAbsoluteOnAnyPlatform and isRelativeOnAnyPlatform are like isAbsolute and isRelative but have platform independent heuristics. The System.FilePath exists in two versions, Windows and Posix. The two versions don't agree on what is a relative path and we don't know if we're given Windows or Posix paths. This results in false positives when running on Posix and inspecting Windows paths, like the hackage server does. System.FilePath.Posix.isAbsolute "C:\hello" == False System.FilePath.Windows.isAbsolute "/hello" == False This means that we would treat paths that start with "/" to be absolute. On Posix they are indeed absolute, while on Windows they are not.

The portable versions should be used when we might deal with paths that are from another OS than the host OS. For example, the Hackage Server deals with both Windows and Posix paths while performing the PackageDescription checks. In contrast, when we run 'cabal configure' we do expect the paths to be correct for our OS and we should not have to use the platform independent heuristics.

isRelativeOnAnyPlatform = not . isAbsoluteOnAnyPlatform