99839e0 · typeable/attoparsec

git.iko.soy/typeable/attoparsec

Case-correct Attoparsec to attoparsec

commit99839e0eb3180d585e39549e57a05da0acb78529 authorBryan O'Sullivan <bos@serpentine.com> dateWed 28 May 2014, 23:11 (12 years ago) parent66424cd

7 files changed+24−24

compare with master

unifiedsplit

Data/Attoparsec/ByteString.hs+9−9 Data/Attoparsec/ByteString/Internal.hs+1−1 Data/Attoparsec/Combinator.hs+1−1 Data/Attoparsec/Internal/Types.hs+1−1 Data/Attoparsec/Text.hs+9−9 Data/Attoparsec/Text/Internal.hs+1−1 Data/Attoparsec/Zepto.hs+2−2

Data/Attoparsec/ByteString.hs+9−9

@@ -100,41 +100,41 @@ import qualified Data.Attoparsec.Internal.Types as T

100100

101101-- $parsec

102102--

103−-- Compared to Parsec 3, Attoparsec makes several tradeoffs. It is

103+-- Compared to Parsec 3, attoparsec makes several tradeoffs. It is

104104-- not intended for, or ideal for, all possible uses.

105105--

106−-- * While Attoparsec can consume input incrementally, Parsec cannot.

106+-- * While attoparsec can consume input incrementally, Parsec cannot.

107107-- Incremental input is a huge deal for efficient and secure network

108108-- and system programming, since it gives much more control to users

109109-- of the library over matters such as resource usage and the I/O

110110-- model to use.

111111--

112−-- * Much of the performance advantage of Attoparsec is gained via

112+-- * Much of the performance advantage of attoparsec is gained via

113113-- high-performance parsers such as 'I.takeWhile' and 'I.string'.

114114-- If you use complicated combinators that return lists of bytes or

115115-- characters, there is less performance difference between the two

116116-- libraries.

117117--

118−-- * Unlike Parsec 3, Attoparsec does not support being used as a

118+-- * Unlike Parsec 3, attoparsec does not support being used as a

119119-- monad transformer.

120120--

121−-- * Attoparsec is specialised to deal only with strict 'B.ByteString'

121+-- * attoparsec is specialised to deal only with strict 'B.ByteString'

122122-- input. Efficiency concerns rule out both lists and lazy

123123-- bytestrings. The usual use for lazy bytestrings would be to

124124-- allow consumption of very large input without a large footprint.

125−-- For this need, Attoparsec's incremental input provides an

125+-- For this need, attoparsec's incremental input provides an

126126-- excellent substitute, with much more control over when input

127127-- takes place. If you must use lazy bytestrings, see the

128128-- "Data.Attoparsec.ByteString.Lazy" module, which feeds lazy chunks

129129-- to a regular parser.

130130--

131131-- * Parsec parsers can produce more helpful error messages than

132−-- Attoparsec parsers. This is a matter of focus: Attoparsec avoids

132+-- attoparsec parsers. This is a matter of focus: attoparsec avoids

133133-- the extra book-keeping in favour of higher performance.

134134

135135-- $incremental

136136--

137−-- Attoparsec supports incremental input, meaning that you can feed it

137+-- attoparsec supports incremental input, meaning that you can feed it

138138-- a bytestring that represents only part of the expected total amount

139139-- of data to parse. If your parser reaches the end of a fragment of

140140-- input and could consume more input, it will suspend parsing and

@@ -158,7 +158,7 @@ import qualified Data.Attoparsec.Internal.Types as T

158158

159159-- $performance

160160--

161−-- If you write an Attoparsec-based parser carefully, it can be

161+-- If you write an attoparsec-based parser carefully, it can be

162162-- realistic to expect it to perform within a factor of 2 of a

163163-- hand-rolled C parser (measuring megabytes parsed per second).

164164--

Data/Attoparsec/ByteString/Internal.hs+1−1

@@ -166,7 +166,7 @@ take n = takeWith n (const True)

166166--

167167-- The reason for its failure is that the first branch is a

168168-- partial match, and will consume the letters @\'f\'@ and @\'o\'@

169−-- before failing. In Attoparsec, the above parser will /succeed/ on

169+-- before failing. In attoparsec, the above parser will /succeed/ on

170170-- that input, because the failed first branch will consume nothing.

171171string :: B.ByteString -> Parser B.ByteString

172172string s = takeWith (B.length s) (==s)

Data/Attoparsec/Combinator.hs+1−1

@@ -46,7 +46,7 @@ import Prelude hiding (succ)

4646-- input appears to have been consumed.

4747--

4848-- This combinator is provided for compatibility with Parsec.

49−-- Attoparsec parsers always backtrack on failure.

49+-- attoparsec parsers always backtrack on failure.

5050try :: Parser i t a -> Parser i t a

5151try p = p

5252{-# INLINE try #-}

Data/Attoparsec/Internal/Types.hs+1−1

@@ -86,7 +86,7 @@ instance Functor (IResult i) where

8686-- 'mplus' executes the right-hand parser if the left-hand one

8787-- fails. When the parser on the right executes, the input is reset

8888-- to the same state as the parser on the left started with. (In

89−-- other words, Attoparsec is a backtracking parser that supports

89+-- other words, attoparsec is a backtracking parser that supports

9090-- arbitrary lookahead.)

9191--

9292-- * 'Alternative', which follows 'MonadPlus'.

Data/Attoparsec/Text.hs+9−9

@@ -140,40 +140,40 @@ import qualified Data.Text as T

140140

141141-- $parsec

142142--

143−-- Compared to Parsec 3, Attoparsec makes several tradeoffs. It is

143+-- Compared to Parsec 3, attoparsec makes several tradeoffs. It is

144144-- not intended for, or ideal for, all possible uses.

145145--

146−-- * While Attoparsec can consume input incrementally, Parsec cannot.

146+-- * While attoparsec can consume input incrementally, Parsec cannot.

147147-- Incremental input is a huge deal for efficient and secure network

148148-- and system programming, since it gives much more control to users

149149-- of the library over matters such as resource usage and the I/O

150150-- model to use.

151151--

152−-- * Much of the performance advantage of Attoparsec is gained via

152+-- * Much of the performance advantage of attoparsec is gained via

153153-- high-performance parsers such as 'I.takeWhile' and 'I.string'.

154154-- If you use complicated combinators that return lists of

155155-- characters, there is less performance difference between the two

156156-- libraries.

157157--

158−-- * Unlike Parsec 3, Attoparsec does not support being used as a

158+-- * Unlike Parsec 3, attoparsec does not support being used as a

159159-- monad transformer.

160160--

161−-- * Attoparsec is specialised to deal only with strict 'Text'

161+-- * attoparsec is specialised to deal only with strict 'Text'

162162-- input. Efficiency concerns rule out both lists and lazy text.

163163-- The usual use for lazy text would be to allow consumption of very

164164-- large input without a large footprint. For this need,

165−-- Attoparsec's incremental input provides an excellent substitute,

165+-- attoparsec's incremental input provides an excellent substitute,

166166-- with much more control over when input takes place. If you must

167167-- use lazy text, see the 'Lazy' module, which feeds lazy chunks to

168168-- a regular parser.

169169--

170170-- * Parsec parsers can produce more helpful error messages than

171−-- Attoparsec parsers. This is a matter of focus: Attoparsec avoids

171+-- attoparsec parsers. This is a matter of focus: attoparsec avoids

172172-- the extra book-keeping in favour of higher performance.

173173

174174-- $incremental

175175--

176−-- Attoparsec supports incremental input, meaning that you can feed it

176+-- attoparsec supports incremental input, meaning that you can feed it

177177-- a 'Text' that represents only part of the expected total amount

178178-- of data to parse. If your parser reaches the end of a fragment of

179179-- input and could consume more input, it will suspend parsing and

@@ -197,7 +197,7 @@ import qualified Data.Text as T

197197

198198-- $performance

199199--

200−-- If you write an Attoparsec-based parser carefully, it can be

200+-- If you write an attoparsec-based parser carefully, it can be

201201-- realistic to expect it to perform within a factor of 2 of a

202202-- hand-rolled C parser (measuring megabytes parsed per second).

203203--

Data/Attoparsec/Text/Internal.hs+1−1

@@ -155,7 +155,7 @@ take n = takeWith (max n 0) (const True)

155155--

156156-- The reason for its failure is that the first branch is a

157157-- partial match, and will consume the letters @\'f\'@ and @\'o\'@

158−-- before failing. In Attoparsec, the above parser will /succeed/ on

158+-- before failing. In attoparsec, the above parser will /succeed/ on

159159-- that input, because the failed first branch will consume nothing.

160160string :: Text -> Parser Text

161161string s = takeWith (T.length s) (==s)

Data/Attoparsec/Zepto.hs+2−2

@@ -12,13 +12,13 @@

1212-- A tiny, highly specialized combinator parser for 'B.ByteString'

1313-- strings.

1414--

15−-- While the main Attoparsec module generally performs well, this

15+-- While the main attoparsec module generally performs well, this

1616-- module is particularly fast for simple non-recursive loops that

1717-- should not normally result in failed parses.

1818--

1919-- /Warning/: on more complex inputs involving recursion or failure,

2020-- parsers based on this module may be as much as /ten times slower/

21−-- than regular Attoparsec! You should /only/ use this module when you

21+-- than regular attoparsec! You should /only/ use this module when you

2222-- have benchmarks that prove that its use speeds your code up.

2323module Data.Attoparsec.Zepto

2424 (