logo
首页技术栈工具库讨论
generic-deriving
generic-deriving
This package provides functionality for generalising the deriving mechanism in Haskell to arbitrary classes. It was first described in the paper: A generic deriving mechanism for Haskell. Jose Pedro Magalhaes, Atze Dijkstra, Johan Jeuring, and Andres Loeh. Haskell'10. The current implementation integrates with the new GHC Generics. See http://www.haskell.org/haskellwiki/GHC.Generics for more information. Template Haskell code is provided for supporting older GHCs. This library is organized as follows: Generics.Deriving.Base defines the core functionality for GHC generics, including the Generic(1) classes and representation data types. On modern versions of GHC, this simply re-exports GHC.Generics from base. On older versions of GHC, this module backports parts of GHC.Generics that were not included at the time, including Generic(1) instances. Generics.Deriving.TH implements Template Haskell functionality for deriving instances of Generic(1). Educational code: in order to provide examples of how to define and use GHC.Generics-based defaults, this library offers a number of modules which define examples of type classes along with default implementations for the classes' methods. Currently, the following modules are provided: Generics.Deriving.Copoint, Generics.Deriving.ConNames, Generics.Deriving.Enum, Generics.Deriving.Eq, Generics.Deriving.Foldable, Generics.Deriving.Functor, Generics.Deriving.Monoid, Generics.Deriving.Semigroup, Generics.Deriving.Show, Generics.Deriving.Traversable, and Generics.Deriving.Uniplate. It is worth emphasizing that these modules are primarly intended for educational purposes. Many of the classes in these modules resemble other commonly used classes—for example, GShow from Generics.Deriving.Show resembles Show from base—but in general, the classes that generic-deriving defines are not drop-in replacements. Moreover, the generic defaults that generic-deriving provide often make simplifying assumptions that may violate expectations of how these classes might work elsewhere. For example, the generic default for GShow does not behave exactly like deriving Show would. If you are seeking GHC.Generics-based defaults for type classes in base, consider using the generic-data library. Generics.Deriving.Default provides newtypes that allow leveraging the generic defaults in this library using the DerivingVia GHC language extension. Generics.Deriving re-exports Generics.Deriving.Base, Generics.Deriving.Default, and a selection of educational modules.
nested-routes
nested-routes
A method to writing Wai responses This library attempts to make it easier to write nice Wai response handlers by giving us a Sinatra/ Scotty-like syntax for declaring HTTP-verb oriented routes, in addition to file-extension handling and rose-tree like composition. Not only do we have literal route specification, like Scotty & Spock, but we can also embed Attoparsec parsers and Regular Expressions directly in our routes, with our handlers reflecting their results. You can find more information on the demo. As an example: The route specification syntax is a little strange right now - l specifies a literal chunk of a handlable url (ie - l "foo" </> l "bar" </> o would represent the url /foo/bar), while p represents a parsable url chunk, which expects a pair - the left element being merely a reference name for the parser during internal plumbing, and the right being the actual Parser. o represents the end of a url string, and can be used alone in a handler to capture requests to the root path. Each route being handled needs some kind of content. For every parsed url chunk, the route expects a function of arity matching 1-for-1 with the parsed contents. For example, d -> ... in the demonstration above is such a function, where d :: Double. Internally, we match against both the file extension and Accept headers in the HTTP request - the Accept header may override the file extension. When we test our application: requests may end with index and specify the file extension each responding with the closest available file type
fclabels
fclabels
This package provides first class labels that can act as bidirectional record fields. The labels can be derived automatically using Template Haskell which means you don't have to write any boilerplate yourself. The labels are implemented as lenses and are fully composable. Lenses can be used to get, set and modify parts of a data type in a consistent way. See Data.Label for an introductory explanation or see the introductory blog post at http://fvisser.nl/post/2013/okt/1/fclabels-2.0.html Total and partial lenses Internally lenses do not used Haskell functions directly, but are implemented as categories. Categories allow the lenses to be run in custom computational contexts. This approach allows us to make partial lenses that point to fields of multi-constructor datatypes in an elegant way. See Data.Label.Partial for the use of partial labels. Monomorphic and polymorphic lenses We have both polymorphic and monomorphic lenses. Polymorphic lenses allow updates that change the type. The types of polymorphic lenses are slightly more verbose than their monomorphic counterparts, but their usage is similar. Because monomorphic lenses are built by restricting the types of polymorphic lenses they are essentially the same and can be freely composed with eachother. See Data.Label.Mono and Data.Label.Poly for the difference between polymorphic and monomorphic lenses. Using fclabels To simplify working with labels we supply both a set of labels for Haskell's base types, like lists, tuples, Maybe and Either, and we supply a set of combinators for working with labels for values in the Reader and State monad. See Data.Label.Base and Data.Label.Monadic for more information. Changelog from 2.0.4 to 2.0.5