eeva/servant
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
servant/servant-foreign/src/Servant/Foreign.hs

62 lines
1.3 KiB
Haskell
Raw Normal View History

Adjust file contents a little.
2015-11-16 18:40:15 +01:00
-- | Generalizes all the data needed to make code generation work with
-- arbitrary programming languages.
doc(servant-foreign): Inflection docs & module docs
2021-02-03 07:52:28 +01:00
--
-- See documentation of 'HasForeignType' for a simple example. 'listFromAPI' returns a list of all your endpoints and their foreign types, given a mapping from Haskell types to foreign types (conventionally called `ftypes` below).
Adjust file contents a little.
2015-11-16 18:40:15 +01:00
module Servant.Foreign
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
(
-- * Main API
listFromAPI
doc(servant-foreign): reorder imports The imports were ordered in the worst possible way, with all undocumented small type definitions coming first and the actual meat of the module coming at the very end, mixed in with irrelevant functions. This inverses that toxic ordering, showing the main function first (`listFromAPI`) and then the main data type (`Req`) and the main class (`HasForeignType`).
2021-02-03 08:03:33 +01:00
, Req(..)
, defReq
, HasForeignType(..)
, GenerateList(..)
, HasForeign(..)
, NoTypes
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
-- * Subtypes of 'Req'
, Url(..)
, Path
Adjust file contents a little.
2015-11-16 18:40:15 +01:00
, Segment(..)
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
, SegmentType(..)
doc(servant-foreign): reorder imports The imports were ordered in the worst possible way, with all undocumented small type definitions coming first and the actual meat of the module coming at the very end, mixed in with irrelevant functions. This inverses that toxic ordering, showing the main function first (`listFromAPI`) and then the main data type (`Req`) and the main class (`HasForeignType`).
2021-02-03 08:03:33 +01:00
, isCapture
, captureArg
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
, QueryArg(..)
, ArgType(..)
, HeaderArg(..)
use newtypes in servant-foreign
2016-02-17 22:47:30 +01:00
, Arg(..)
, FunctionName(..)
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
, ReqBodyContentType(..)
use newtypes in servant-foreign
2016-02-17 22:47:30 +01:00
, PathSegment(..)
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
-- * Lenses
[servant-foreign] Normalise names of arg field accessors
2016-03-13 05:02:00 +01:00
, argName
, argType
, argPath
Adjust file contents a little.
2015-11-16 18:40:15 +01:00
, reqUrl
, reqMethod
Make servant-foreign code nicer * non-messy imports * got rid of most long lines (>80 chars) * prisms for sum types and newtypes(we use lens anyway, so why not) * consistent indentation
2016-02-11 11:41:34 +01:00
, reqHeaders
, reqBody
introduce type ReqBodyContentType replacing use of Bool
2018-09-17 23:19:41 +02:00
, reqBodyContentType
Add access to types in servant-foreign.
2015-11-28 09:13:26 +01:00
, reqReturnType
Make servant-foreign code nicer * non-messy imports * got rid of most long lines (>80 chars) * prisms for sum types and newtypes(we use lens anyway, so why not) * consistent indentation
2016-02-11 11:41:34 +01:00
, reqFuncName
, path
Adjust file contents a little.
2015-11-16 18:40:15 +01:00
, queryStr
[servant-foreign] Normalise names of arg field accessors
2016-03-13 05:02:00 +01:00
, queryArgName
, queryArgType
use newtypes in servant-foreign
2016-02-17 22:47:30 +01:00
, headerArg
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
-- * Prisms
use newtypes in servant-foreign
2016-02-17 22:47:30 +01:00
, _PathSegment
Make servant-foreign code nicer * non-messy imports * got rid of most long lines (>80 chars) * prisms for sum types and newtypes(we use lens anyway, so why not) * consistent indentation
2016-02-11 11:41:34 +01:00
, _HeaderArg
, _ReplaceHeaderArg
, _Static
, _Cap
, _Normal
, _Flag
, _List
doc(servant-foreign): Document module I spend some considerable time reverse engineering the module, so I thought I’d write the documentation I would have liked to see. The strategy here is that a user not necessarily has insight into how servant works internally, or even how to write complex servant routes, they just want to generate a list of endpoints and convert the `Req` type into e.g. generated code in $language. Thus, they need to know the semantics of all fields of Req, how they interact and how they relate to a plain http route. I made sure every `f` is replaced with `ftype`, so we have one conventional way of referring to the foreign type argument everywhere. Some enums are not set at all, they are marked as such. `_reqBodyContentType` introduces a major restriction of the module, so that is mentioned in the documentation for now, until the time it will be fixed. A few TODO’s describe places where types don’t make sense but would introduce API-breaking changes, so these should probably be simplified, but bundled in one go.
2021-02-03 17:12:57 +01:00
-- * Re-exports
Adjust file contents a little.
2015-11-16 18:40:15 +01:00
, module Servant.API
use newtypes in servant-foreign
2016-02-17 22:47:30 +01:00
, module Servant.Foreign.Inflections
Adjust file contents a little.
2015-11-16 18:40:15 +01:00
) where
Apply stylish-haskell on all modules
2018-06-29 21:08:26 +02:00
import Servant.API
import Servant.Foreign.Inflections
import Servant.Foreign.Internal
Reference in a new issue Copy permalink