Fix typos and grammar (#1304)

* Fix typos and grammar

* Remove redundant words, fix articles

* More language fixes

* More typo fixes and resolve TODO about missing links

CONTRIBUTING.md

@@ -103,7 +103,7 @@ the `news` label if you make a new package so we can know about it!
 
 ## Release policy
 
-We are currently moving to a more aggresive release policy, so that you can get
+We are currently moving to a more aggressive release policy, so that you can get
 what you contribute from Hackage fairly soon. However, note that prior to major
 releases it may take some time in between releases.
 

README.md

@@ -32,7 +32,7 @@ See `CONTRIBUTING.md`
         - It's a good idea to separate these steps, as tests often pass, if they compile :)
     - See `cabal.project` to selectively `allow-newer`
     - If some packages are broken, on your discretisation there are two options:
-        - Fix them and make PRs: it's good idea to test against older `servant` version too.
+        - Fix them and make PRs: it's a good idea to test against older `servant` version too.
         - Temporarily comment out broken package
     - If you make a commit for `servant-universe`, you can use it as submodule in private projects to test even more
 - When ripples are cleared out:
@@ -60,7 +60,7 @@ constraints:
   troublemaker <13.37 && > 13.37
 ```
 
-## TechEmpower framework bechmarks
+## TechEmpower framework benchmarks
 
 We develop and maintain the servant TFB entry in https://github.com/haskell-servant/FrameworkBenchmarks/
 

doc/cookbook/basic-streaming/Streaming.lhs

@@ -8,7 +8,10 @@ In other words, without streaming libraries.
 - Some basic usage doesn't require usage of streaming libraries,
   like `conduit`, `pipes`, `machines` or `streaming`.
   We have bindings for them though.
-- This is similar example file, which is bundled with each of the packages (TODO: links)
+- Similar example is bundled with each of our streaming library interop packages (see 
+[servant-pipes](https://github.com/haskell-servant/servant/blob/master/servant-pipes/example/Main.hs),
+[servant-conduit](https://github.com/haskell-servant/servant/blob/master/servant-conduit/example/Main.hs) and
+[servant-machines](https://github.com/haskell-servant/servant/blob/master/servant-machines/example/Main.hs))
 - `SourceT` doesn't have *Prelude* with handy combinators, so we have to write
   things ourselves. (Note to self: `mapM` and `foldM` would be handy to have). 
 

doc/cookbook/curl-mock/CurlMock.lhs

@@ -1,7 +1,7 @@
 # Generating mock curl calls
 
 In this example we will generate curl requests with mock post data from a servant API.
-This may be usefull for testing and development purposes.
+This may be useful for testing and development purposes.
 Especially post requests with a request body are tedious to send manually.
 
 Also, we will learn how to use the servant-foreign library to generate stuff from servant APIs.

doc/cookbook/db-mysql-basics/MysqlBasics.lhs

@@ -2,7 +2,7 @@
 
 This doc will walk through a single-module implementation of a servant API connecting to a MySQL database. It will also include some basic CRUD operations.
 
-Once you can wrap your head around this implemenation, understanding more complex features like resource pools would be beneficial next steps.
+Once you can wrap your head around this implementation, understanding more complex features like resource pools would be beneficial next steps.
 
 The only *prerequisite* is that you have a MySQL database open on port 3306 of your machine. Docker is an easy way to manage this.
 

doc/cookbook/file-upload/FileUpload.lhs

@@ -90,8 +90,8 @@ startServer = run 8080 (serve api upload)
 
 Finally, a main function that brings up our server and
 sends some test request with `http-client` (and not
-servant-client this time, has servant-multipart does not
+servant-client this time, as servant-multipart does not
-yet have support for client generation.
+yet have support for client generation).
 
 ``` haskell
 main :: IO ()

doc/cookbook/generic/Generic.lhs

@@ -43,13 +43,13 @@ api :: Proxy (ToServantApi Routes)
 api = genericApi (Proxy :: Proxy Routes)
 ```
 
-It's recommented to use `genericApi` function, as then you'll get
+It's recommended to use `genericApi` function, as then you'll get
 better error message, for example if you forget to `derive Generic`.
 
 ## Links
 
 The clear advantage of record-based generics approach, is that
-we can get safe links very conviently. We don't need to define endpoint types,
+we can get safe links very conveniently. We don't need to define endpoint types,
 as field accessors work as proxies:
 
 ```haskell
@@ -67,7 +67,7 @@ routesLinks = allFieldLinks
 ## Client
 
 Even more power starts to show when we generate a record of client functions.
-Here we use `genericClientHoist` function, which let us simultaneously
+Here we use `genericClientHoist` function, which lets us simultaneously
 hoist the monad, in this case from `ClientM` to `IO`.
 
 ```haskell

doc/cookbook/hoist-server-with-context/HoistServerWithContext.lhs

@@ -254,7 +254,7 @@ loginHandler cookieSettings jwtSettings form = do
           liftIO $ pushLogStrLn logset $ toLogStr logMsg
           throwError err401
         Just applyCookies -> do
-          let successMsg = logMsg{message = "AdminUser succesfully authenticated!"}
+          let successMsg = logMsg{message = "AdminUser successfully authenticated!"}
           liftIO $ pushLogStrLn logset $ toLogStr successMsg
           pure $ applyCookies successMsg
 loginHandler _ _ _ = throwError err401

doc/cookbook/open-id-connect/OpenIdConnect.lhs

@@ -8,7 +8,7 @@ some login token would be saved in the user agent local storage.
 
 Workflow:
 
-1.  user is presentend with a login button,
+1.  user is presented with a login button,
 2.  when the user click on the button it is redirected to the OIDC
     provider,
 3.  the user login in the OIDC provider,
@@ -222,8 +222,8 @@ The `AuthInfo` is about the infos we can grab from OIDC provider.
 To be more precise, the user should come with a `code` (a token) and
 POSTing that code to the correct OIDC provider endpoint should return a JSON
 object. One of the field should be named `id_token` which should be a
-JWT containing all the informations we need. Depending on the scopes we
+JWT containing all the information we need. Depending on the scopes we
-asked we might get more informations.
+asked we might get more information.
 
 ``` haskell
 -- | @AuthInfo@
@@ -248,13 +248,13 @@ instance JSON.ToJSON AuthInfo where
 type LoginHandler = AuthInfo -> IO (Either Text User)
 ```
 
-The `handleLoggedIn` is that part that will retrieve the informations from
+The `handleLoggedIn` is that part that will retrieve the information from
 the user once he is redirected from the OIDC Provider after login.
 
 If the user is redirected to the `redirect_uri` but with an `error` query
 parameter then it means something goes wrong.
 If there is no error query param but a `code` query param it means the user
-sucessfully logged in. From there we need to make a request to the token
+successfully logged in. From there we need to make a request to the token
 endpoint of the OIDC provider. Its a POST that should contains the code
 as well as the client id & secret.
 This is the role of the `requestTokens` to make this HTTP POST.
@@ -332,7 +332,7 @@ data Customer = Customer {
 Here is the code that display the homepage.
 It should contain a link to the the `/login` URL.
 When the user will click on this link it will be redirected to Google login page
-with some generated informations.
+with some generated information.
 
 The page also display the content of the local storage.
 And in particular the items `api-key` and `user-id`.
@@ -366,7 +366,7 @@ instance ToMarkup Homepage where
 We need some helpers to generate random string for generating state and API Keys.
 
 ``` haskell
--- | generate a random Bystestring, not necessarily extremely good randomness
+-- | generate a random ByteString, not necessarily extremely good randomness
 -- still the password will be long enough to be very difficult to crack
 genRandomBS :: IO ByteString
 genRandomBS = do

doc/cookbook/pagination/Pagination.lhs

@@ -18,7 +18,7 @@ For example: `Range: createdAt 2017-01-15T23:14:67.000Z; offset 5; order desc` i
 the client is willing to retrieve the next batch of document in descending order that were
 created after the fifteenth of January, skipping the first 5.
 
-As a response, the server may return the list of corresponding document, and augment the
+As a response, the server may return the list of corresponding documents, and augment the
 response with 3 headers:
 
 - `Accept-Ranges`: A comma-separated list of fields upon which a range can be defined
@@ -127,7 +127,7 @@ defaultRange =
   getDefaultRange (Proxy @Color)
 ```
 
-Note that `getFieldValue :: Proxy "name" -> Color -> String` is the minimal complete definintion
+Note that `getFieldValue :: Proxy "name" -> Color -> String` is the minimal complete definition
 of the class. Yet, you can define `getRangeOptions` to provide different parsing options (see
 the last section of this guide). In the meantime, we've also defined a `defaultRange` as it will
 come in handy when defining our handler.
@@ -148,7 +148,7 @@ type MyHeaders =
 ```
 
 `PageHeaders` is a type alias provided by the library to declare the necessary response headers
-we mentionned in introduction. Expanding the alias boils down to the following:
+we mentioned in introduction. Expanding the alias boils down to the following:
 
 ``` haskell
 -- type MyHeaders =
@@ -165,7 +165,7 @@ not, _servant-pagination_ provides an easy way to lift a collection of resources
 #### Server
 
 Time to connect the last bits by defining the server implementation of our colorful API. The `Ranges`
-type we've defined above (tight to the `Range` HTTP header) indicates the server to parse any `Range`
+type we've defined above (tied to the `Range` HTTP header) indicates the server to parse any `Range`
 header, looking for the format defined in introduction with fields and target types we have just declared.
 If no such header is provided, we will end up receiving `Nothing`. Otherwise, it will be possible
 to _extract_ a `Range` from our `Ranges`.
@@ -192,7 +192,7 @@ the format we defined, where `<field>` here can only be `name` and `<value>` mus
 - `Range: <field> [<value>][; offset <o>][; limit <l>][; order <asc|desc>]`
 
 Beside the target field, everything is pretty much optional in the `Range` HTTP header. Missing parts
-are deducted from the `RangeOptions` that are part of the `HasPagination` instance. Therefore, all
+are deduced from the `RangeOptions` that are part of the `HasPagination` instance. Therefore, all
 following examples are valid requests to send to our server:
 
 - 1 - `curl http://localhost:1442/colors -vH 'Range: name'`
@@ -219,7 +219,7 @@ The previous ranges reads as follows:
 Note that in the simple above scenario, there's no ambiguity with `extractRange` and `returnRange`
 because there's only one possible `Range` defined on our resource. Yet, as you've most probably
 noticed, the `Ranges` combinator accepts a list of fields, each of which must declare a `HasPagination`
-instance. Doing so will make the other helper functions more ambiguous and type annotation are
+instance. Doing so will make the other helper functions more ambiguous and type annotations are
 highly likely to be needed.
 
 
@@ -235,8 +235,8 @@ instance HasPagination Color "hex" where
 #### Parsing Options
 
 By default, `servant-pagination` provides an implementation of `getRangeOptions` for each
-`HasPagination` instance. However, this can be overwritten when defining the instance to provide
+`HasPagination` instance. However, this can be overridden when defining the instance to provide
-your own options. This options come into play when a `Range` header is received and isn't fully
+your own options. These options come into play when a `Range` header is received and isn't fully
 specified (`limit`, `offset`, `order` are all optional) to provide default fallback values for those.
 
 For instance, let's say we wanted to change the default limit to `5` in a new range on

doc/cookbook/sentry/Sentry.lhs

@@ -79,7 +79,7 @@ It does three things. First it initializes the service which will communicate wi
 
 - the Sentry `DSN`, which is obtained when creating a new project on Sentry
 - a default way to update sentry fields, where we use the identity function
-- an event trasport, which generally would be `sendRecord`, an HTTPS capable trasport which uses http-conduit
+- an event transport, which generally would be `sendRecord`, an HTTPS capable transport which uses http-conduit
 - a fallback handler, which we choose to be `silentFallback` since later we are logging to the console anyway.
 
 In the second step it actually sends our message to Sentry with the `register` function. Its arguments are:

doc/cookbook/structuring-apis/StructuringApis.lhs

@@ -144,7 +144,7 @@ simpleAPIServer
   :: m [a]
   -> (i -> m a)
   -> (a -> m NoContent)
-  -> Server (SimpleAPI name a i) m
+  -> ServerT (SimpleAPI name a i) m
 simpleAPIServer listAs getA postA =
   listAs :<|> getA :<|> postA
 

doc/cookbook/using-custom-monad/UsingCustomMonad.lhs

@@ -1,6 +1,6 @@
 # Using a custom monad
 
-In this section we will create and API for a book shelf without any backing DB storage.
+In this section we will create an API for a book shelf without any backing DB storage.
 We will keep state in memory and share it between requests using `Reader` monad and `STM`.
 
 We start with a pretty standard set of imports and definition of the model:

doc/cookbook/using-free-client/UsingFreeClient.lhs

@@ -141,7 +141,7 @@ and calling the continuation. We should get a `Pure` value.
             Pure n ->
                 putStrLn $ "Expected 1764, got " ++ show n
             _ ->
-                putStrLn "ERROR: didn't got a response"
+                putStrLn "ERROR: didn't get a response"
 ```
 
 So that's it. Using `Free` we can evaluate servant clients step-by-step, and

doc/tutorial/Authentication.lhs

@@ -108,7 +108,7 @@ API with "private." Additionally, the private parts of our API use the
 realm for this authentication is `"foo-realm"`).
 
 Unfortunately we're not done. When someone makes a request to our `"private"`
-API, we're going to need to provide to servant the logic for validifying
+API, we're going to need to provide to servant the logic for validating
 usernames and passwords. This adds a certain conceptual wrinkle in servant's
 design that we'll briefly discuss. If you want the **TL;DR**: we supply a lookup
 function to servant's new `Context` primitive.
@@ -260,7 +260,7 @@ this.
 
 Let's implement a trivial authentication scheme. We will protect our API by
 looking for a cookie named `"servant-auth-cookie"`. This cookie's value will
-contain a key from which we can lookup a `Account`.
+contain a key from which we can lookup an `Account`.
 
 ```haskell
 -- | An account type that we "fetch from the database" after
@@ -274,7 +274,7 @@ database = fromList [ ("key1", Account "Anne Briggs")
                     , ("key3", Account "Ghédalia Tazartès")
                     ]
 
--- | A method that, when given a password, will return a Account.
+-- | A method that, when given a password, will return an Account.
 -- This is our bespoke (and bad) authentication logic.
 lookupAccount :: ByteString -> Handler Account
 lookupAccount key = case Map.lookup key database of
@@ -346,7 +346,7 @@ genAuthServerContext = authHandler :. EmptyContext
 
 -- | Our API, where we provide all the author-supplied handlers for each end
 -- point. Note that 'privateDataFunc' is a function that takes 'Account' as an
--- argument. We dont' worry about the authentication instrumentation here,
+-- argument. We don't worry about the authentication instrumentation here,
 -- that is taken care of by supplying context
 genAuthServer :: Server AuthGenAPI
 genAuthServer =
@@ -385,11 +385,11 @@ Creating a generalized, ad-hoc authentication scheme was fairly straight
 forward:
 
 1. use the `AuthProtect` combinator to protect your API.
-2. choose a application-specific data type used by your server when
+2. choose an application-specific data type used by your server when
 authentication is successful (in our case this was `Account`).
 3. Create a value of `AuthHandler Request Account` which encapsulates the
 authentication logic (`Request -> Handler Account`). This function
-will be executed everytime a request matches a protected route.
+will be executed every time a request matches a protected route.
 4. Provide an instance of the `AuthServerData` type family, specifying your
 application-specific data type returned when authentication is successful (in
 our case this was `Account`).

doc/tutorial/Client.lhs

@@ -161,7 +161,7 @@ The types of the arguments for the functions are the same as for (server-side) r
 ## Changing the monad the client functions live in
 
 Just like `hoistServer` allows us to change the monad in which request handlers
-of a web application live in, we also have `hoistClient` for changing the monad
+of a web application live, we also have `hoistClient` for changing the monad
 in which _client functions_ live. Consider the following trivial API:
 
 ``` haskell
@@ -173,7 +173,7 @@ hoistClientAPI = Proxy
 
 We already know how to derive client functions for this API, and as we have
 seen above they all return results in the `ClientM` monad when using `servant-client`.
-However, `ClientM` rarely (or never) is the actual monad we need to use the client
+However, `ClientM` is rarely (or never) the actual monad we need to use the client
 functions in. Sometimes we need to run them in IO, sometimes in a custom monad
 stack. `hoistClient` is a very simple solution to the problem of "changing" the monad
 the clients run in.

doc/tutorial/Docs.lhs

@@ -77,7 +77,7 @@ instance ToSample HelloMessage where
     [ ("When a value is provided for 'name'", HelloMessage "Hello, Alp")
     , ("When 'name' is not specified", HelloMessage "Hello, anonymous coward")
     ]
-    -- mutliple examples to display this time
+    -- multiple examples to display this time
 
 ci :: ClientInfo
 ci = ClientInfo "Alp" "alp@foo.com" 26 ["haskell", "mathematics"]
@@ -108,7 +108,7 @@ apiDocs = docs exampleAPI
 markdown :: API -> String
 ```
 
-That lets us see what our API docs look down in markdown, by looking at `markdown apiDocs`.
+That lets us see what our API docs look like in markdown, by looking at `markdown apiDocs`.
 
 ````````` text
 ## GET /hello

doc/tutorial/Javascript.lhs

@@ -228,13 +228,13 @@ data CommonGeneratorOptions = CommonGeneratorOptions
   {
     -- | function generating function names
     functionNameBuilder :: FunctionName -> Text
-    -- | name used when a user want to send the request body (to let you redefine it)
+    -- | name used when a user wants to send the request body (to let you redefine it)
   , requestBody :: Text
     -- | name of the callback parameter when the request was successful
   , successCallback :: Text
     -- | name of the callback parameter when the request reported an error
   , errorCallback :: Text
-    -- | namespace on which we define the js function (empty mean local var)
+    -- | namespace on which we define the js function (empty means local var)
   , moduleName :: Text
     -- | a prefix that should be prepended to the URL in the generated JS
   , urlPrefix :: Text

doc/tutorial/Server.lhs

@@ -183,7 +183,7 @@ users2 = [isaac, albert]
 
 Now, just like we separate the various endpoints in `UserAPI` with `:<|>`, we
 are going to separate the handlers with `:<|>` too! They must be provided in
-the same order as in in the API type.
+the same order as in the API type.
 
 ``` haskell
 server2 :: Server UserAPI2
@@ -716,7 +716,7 @@ $ curl --verbose http://localhost:8081/myfile.txt
 >
 < HTTP/1.1 404 Not Found
 [snip]
-myfile.txt just isnt there, please leave this server alone.
+myfile.txt just isn't there, please leave this server alone.
 
 $ echo Hello > myfile.txt
 
@@ -818,7 +818,7 @@ If it doesn't exist, the handler will fail with a `404` status code.
 
 `serveDirectoryWebApp` uses some standard settings that fit the use case of
 serving static files for most web apps. You can find out about the other
-options in the documentation of the `Servant.Utils.StaticFiles` module.
+options in the documentation of the `Servant.Server.StaticFiles` module.
 
 ## Nested APIs
 
@@ -1135,7 +1135,7 @@ true
 ### An arrow is a reader too.
 
 In previous versions of `servant` we had an `enter` to do what `hoistServer`
-does now. `enter` had a ambitious design goals, but was problematic in practice.
+does now. `enter` had an ambitious design goals, but was problematic in practice.
 
 One problematic situation was when the source monad was `(->) r`, yet it's
 handy in practice, because `(->) r` is isomorphic to `Reader r`.
@@ -1166,7 +1166,7 @@ back a *stream* of results, served one at a time. Stream endpoints only provide
 a single content type, and also specify what framing strategy is used to
 delineate the results. To serve these results, we need to give back a stream
 producer. Adapters can be written to *Pipes*, *Conduit* and the like, or
-written directly as `SourceIO`s. SourceIO builts upon servant's own `SourceT`
+written directly as `SourceIO`s. SourceIO builds upon servant's own `SourceT`
 stream type (it's simpler than *Pipes* or *Conduit*).
 The API of a streaming endpoint needs to explicitly specify which sort of
 generator it produces. Note that the generator itself is returned by a

servant-client-core/CHANGELOG.md

@@ -205,7 +205,7 @@
 
 - *servant-client-core* Add `hoistClient` to `HasClient`.
   Just like `hoistServer` allows us to change the monad in which request handlers
-  of a web application live in, we also have `hoistClient` for changing the monad
+  of a web application live, we also have `hoistClient` for changing the monad
   in which *client functions* live.
   Read [tutorial section for more information](https://docs.servant.dev/en/release-0.14/tutorial/Client.html#changing-the-monad-the-client-functions-live-in).
   ([#936](https://github.com/haskell-servant/servant/pull/936))

servant-client-core/servant-client-core.cabal

@@ -104,7 +104,7 @@ test-suite spec
     , base-compat
     , servant-client-core
 
-  -- Additonal dependencies
+  -- Additional dependencies
   build-depends:
       deepseq    >= 1.4.2.0  && < 1.5
     , hspec      >= 2.6.0    && < 2.8

servant-client/CHANGELOG.md

@@ -198,7 +198,7 @@
 
 - *servant-client-core* Add `hoistClient` to `HasClient`.
   Just like `hoistServer` allows us to change the monad in which request handlers
-  of a web application live in, we also have `hoistClient` for changing the monad
+  of a web application live, we also have `hoistClient` for changing the monad
   in which *client functions* live.
   Read [tutorial section for more information](https://docs.servant.dev/en/release-0.14/tutorial/Client.html#changing-the-monad-the-client-functions-live-in).
   ([#936](https://github.com/haskell-servant/servant/pull/936))

servant-client/servant-client.cabal

@@ -120,7 +120,7 @@ test-suite spec
     , wai
     , warp
 
-  -- Additonal dependencies
+  -- Additional dependencies
   build-depends:
       entropy           >= 0.4.1.3  && < 0.5
     , hspec             >= 2.6.0    && < 2.8

servant-client/src/Servant/Client/Internal/HttpClient/Streaming.hs

@@ -130,7 +130,7 @@ withClientM cm env k =
 -- streaming response types ('SourceT', 'Conduit', pipes 'Proxy' or 'Machine').
 -- For those you have to use 'withClientM'.
 --
--- /Note:/ we 'force' the result, so the likehood of accidentally leaking a
+-- /Note:/ we 'force' the result, so the likelihood of accidentally leaking a
 -- connection is smaller. Use with care.
 --
 runClientM :: NFData a => ClientM a -> ClientEnv -> IO (Either ClientError a)

servant-docs/example/greet.md

@@ -57,7 +57,7 @@ You'll also note that multiple intros are possible.
 
 This is some text
 
-### Second secton
+### Second section
 
 And some more
 

servant-docs/servant-docs.cabal

@@ -105,7 +105,7 @@ test-suite spec
     , servant-docs
     , string-conversions
 
-  -- Additonal dependencies
+  -- Additional dependencies
   build-depends:
       tasty         >= 1.1.0.4  && < 1.3,
       tasty-golden  >= 2.3.2    && < 2.4,

servant-docs/src/Servant/Docs/Internal.hs

@@ -396,7 +396,7 @@ docsWithOptions p = docsFor p (defEndpoint, defAction)
 -- >     extraInfo (Proxy :: Proxy ("greet" :> Capture "greetid" Text :> Delete)) $
 -- >              defAction & headers <>~ ["unicorns"]
 -- >                        & notes   <>~ [ DocNote "Title" ["This is some text"]
--- >                                      , DocNote "Second secton" ["And some more"]
+-- >                                      , DocNote "Second section" ["And some more"]
 -- >                                      ]
 
 extraInfo :: (IsIn endpoint api, HasLink endpoint, HasDocs endpoint)

servant-foreign/servant-foreign.cabal

@@ -77,7 +77,7 @@ test-suite spec
     , servant
     , servant-foreign
 
-  -- Additonal dependencies
+  -- Additional dependencies
   build-depends:
     hspec >= 2.6.0 && <2.8
 

servant-foreign/test/Servant/ForeignSpec.hs

@@ -114,7 +114,7 @@ listFromAPISpec = describe "listFromAPI" $ do
     shouldBe putReq $ defReq
       { _reqUrl        = Url
           [ Segment $ Static "test" ]
-          -- Shoud this be |intX| or |listX of intX| ?
+          -- Should this be |intX| or |listX of intX| ?
           [ QueryArg (Arg "params" "listX of intX") List ]
       , _reqMethod     = "PUT"
       , _reqHeaders    = []

servant-http-streams/servant-http-streams.cabal

@@ -114,7 +114,7 @@ test-suite spec
     , wai
     , warp
 
-  -- Additonal dependencies
+  -- Additional dependencies
   build-depends:
       entropy           >= 0.4.1.3  && < 0.5
     , hspec             >= 2.6.0    && < 2.8

servant-http-streams/test/Servant/ClientSpec.hs

@@ -77,7 +77,7 @@ _ = client comprehensiveAPIWithoutStreaming
 
 spec :: Spec
 spec = describe "Servant.HttpStreams" $ do
-    sucessSpec
+    successSpec
     failSpec
     wrappedApiSpec
     basicAuthSpec
@@ -262,8 +262,8 @@ runClientUnsafe x burl = withClientEnvIO burl (runClientMUnsafe x)
   where
     runClientMUnsafe x env = withClientM x env return
 
-sucessSpec :: Spec
+successSpec :: Spec
-sucessSpec = beforeAll (startWaiApp server) $ afterAll endWaiApp $ do
+successSpec = beforeAll (startWaiApp server) $ afterAll endWaiApp $ do
     it "Servant.API.Get root" $ \(_, baseUrl) -> do
       left show <$> runClient getRoot baseUrl  `shouldReturn` Right carol
 

servant-server/CHANGELOG.md

@@ -35,7 +35,7 @@
   Some APIs need query parameters rewriting, e.g. in order to support
    for multiple casing (camel, snake, etc) or something to that effect.
 
-  This could be easily achieved by using WAI Middleware and modyfing
+  This could be easily achieved by using WAI Middleware and modifying
   request's `Query`. But QueryParam, QueryParams and QueryFlag use
   `rawQueryString`. By using `queryString` rather then `rawQueryString`
   we can enable such rewritings.
@@ -44,7 +44,7 @@
 
   We used `build-type: Custom`, but it's problematic e.g.
   for cross-compiling. The benefit is small, as the doctests
-  can be run other ways too (though not so conviniently).
+  can be run other ways too (though not so conveniently).
 
 0.16.2
 ------

servant-server/example/README.md

@@ -1,2 +1,2 @@
 - `greet.hs` shows how to write a simple webservice, run it, query it with automatically-derived haskell functions and print the (generated) markdown documentation for the API.
-- `greet.md` contains the aforementionned generated documentation.
+- `greet.md` contains the aforementioned generated documentation.

servant-server/servant-server.cabal

@@ -155,7 +155,7 @@ test-suite spec
     , transformers-compat
     , wai
 
-  -- Additonal dependencies
+  -- Additional dependencies
   build-depends:
       aeson                >= 1.4.1.0  && < 1.5
     , directory            >= 1.3.0.0  && < 1.4

servant-server/src/Servant/Server/Internal.hs

@@ -808,7 +808,7 @@ instance (HasContextEntry context (NamedContext name subContext), HasServer subA
 instance TypeError (HasServerArrowKindError arr) => HasServer ((arr :: k -> l) :> api) context
   where
     type ServerT (arr :> api) m = TypeError (HasServerArrowKindError arr)
-    -- it doens't really matter what sub route we peak
+    -- it doesn't really matter what sub route we peak
     route _ _ _ = error "servant-server panic: impossible happened in HasServer (arr :> api)"
     hoistServerWithContext _ _ _ = id
 

servant-server/src/Servant/Server/Internal/BasicAuth.hs

@@ -32,7 +32,7 @@ import           Servant.Server.Internal.ServerError
 -- * Basic Auth
 
 -- | servant-server's current implementation of basic authentication is not
--- immune to certian kinds of timing attacks. Decoding payloads does not take
+-- immune to certain kinds of timing attacks. Decoding payloads does not take
 -- a fixed amount of time.
 
 -- | The result of authentication/authorization

servant-server/src/Servant/Server/Internal/Context.hs

@@ -20,7 +20,7 @@ import           GHC.TypeLits
 --
 -- If you are using combinators that require a non-empty 'Context' you have to
 -- use 'Servant.Server.serveWithContext' and pass it a 'Context' that contains all
--- the values your combinators need. A 'Context' is essentially a heterogenous
+-- the values your combinators need. A 'Context' is essentially a heterogeneous
 -- list and accessing the elements is being done by type (see 'getContextEntry').
 -- The parameter of the type 'Context' is a type-level list reflecting the types
 -- of the contained context entries. To create a 'Context' with entries, use the

servant-server/src/Servant/Server/Internal/Delayed.hs

@@ -268,5 +268,5 @@ runAction action env req respond k = runResourceT $
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Due to GHC issue <https://ghc.haskell.org/trac/ghc/ticket/2595 2595>, we cannot
-do the more succint thing - just update the records we actually change.
+do the more succinct thing - just update the records we actually change.
 -}

servant-server/src/Servant/Server/Internal/DelayedIO.hs

@@ -24,7 +24,7 @@ import           Servant.Server.Internal.ServerError
 
 -- | Computations used in a 'Delayed' can depend on the
 -- incoming 'Request', may perform 'IO', and result in a
--- 'RouteResult', meaning they can either suceed, fail
+-- 'RouteResult', meaning they can either succeed, fail
 -- (with the possibility to recover), or fail fatally.
 --
 newtype DelayedIO a = DelayedIO { runDelayedIO' :: ReaderT Request (ResourceT (RouteResultT IO)) a }

servant/CHANGELOG.md

@@ -41,7 +41,7 @@
   Some APIs need query parameters rewriting, e.g. in order to support
    for multiple casing (camel, snake, etc) or something to that effect.
 
-  This could be easily achieved by using WAI Middleware and modyfing
+  This could be easily achieved by using WAI Middleware and modifying
   request's `Query`. But QueryParam, QueryParams and QueryFlag use
   `rawQueryString`. By using `queryString` rather then `rawQueryString`
   we can enable such rewritings.
@@ -50,7 +50,7 @@
 
   We used `build-type: Custom`, but it's problematic e.g.
   for cross-compiling. The benefit is small, as the doctests
-  can be run other ways too (though not so conviniently).
+  can be run other ways too (though not so conveniently).
 
 - *servant* Remove deprecated modules [1268#](https://github.com/haskell-servant/servant/pull/1268)
   
@@ -405,7 +405,7 @@
 
 - *servant-client-core* Add `hoistClient` to `HasClient`.
   Just like `hoistServer` allows us to change the monad in which request handlers
-  of a web application live in, we also have `hoistClient` for changing the monad
+  of a web application live, we also have `hoistClient` for changing the monad
   in which *client functions* live.
   Read [tutorial section for more information](https://docs.servant.dev/en/release-0.14/tutorial/Client.html#changing-the-monad-the-client-functions-live-in).
   ([#936](https://github.com/haskell-servant/servant/pull/936))
@@ -612,7 +612,7 @@
 
   `enter` isn't exported from `Servant` module anymore. You can change
   `enter` to `hoistServer` in a straight forward way.
-  Unwrap natural transformation and add a api type `Proxy`:
+  Unwrap natural transformation and add an api type `Proxy`:
 
   ```diff
   -server = enter (NT nt) impl

servant/servant.cabal

@@ -157,7 +157,7 @@ test-suite spec
     , text
     , transformers
 
-  -- Additonal dependencies
+  -- Additional dependencies
   build-depends:
       hspec                >= 2.6.0    && < 2.8
     , QuickCheck           >= 2.12.6.1 && < 2.15

servant/src/Servant/API/ResponseHeaders.hs

@@ -95,7 +95,7 @@ type family HeaderValMap (f :: * -> *) (xs :: [*]) where
 
 class BuildHeadersTo hs where
     buildHeadersTo :: [HTTP.Header] -> HList hs
-    -- ^ Note: if there are multiple occurences of a header in the argument,
+    -- ^ Note: if there are multiple occurrences of a header in the argument,
     -- the values are interspersed with commas before deserialization (see
     -- <http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 RFC2616 Sec 4.2>)
 

servant/src/Servant/Links.hs

@@ -54,7 +54,7 @@
 -- >>> toUrlPiece $ safeLink api without
 -- "bye"
 --
--- If you would like create a helper for generating links only within that API,
+-- If you would like to create a helper for generating links only within that API,
 -- you can partially apply safeLink if you specify a correct type signature
 -- like so:
 --
@@ -65,7 +65,7 @@
 -- >>>     apiLink = safeLink api
 -- >>> :}
 --
--- `safeLink'` allows to make specialise the output:
+-- `safeLink'` allows you to specialise the output:
 --
 -- >>> safeLink' toUrlPiece api without
 -- "bye"
@@ -563,7 +563,7 @@ instance HasLink sub => HasLink (AuthProtect tag :> sub) where
   type MkLink (AuthProtect tag :> sub) a = MkLink sub a
   toLink = simpleToLink (Proxy :: Proxy sub)
 
--- | Helper for implemneting 'toLink' for combinators not affecting link
+-- | Helper for implementing 'toLink' for combinators not affecting link
 -- structure.
 simpleToLink
     :: forall sub a combinator.