Hoogle Search

Within LTS Haskell 24.2 (ghc-9.10.2)

Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.

module Elm.Derive

This module should be used to derive the Elm instance alongside the JSON ones. The prefered usage is to convert statements such as :
```
$(deriveJSON defaultOptions{fieldLabelModifier = drop 4, constructorTagModifier = map toLower} ''D)
```
into:
```
$(deriveBoth defaultOptions{fieldLabelModifier = drop 4, constructorTagModifier = map toLower} ''D)
```
Which will derive both the aeson and elm-bridge instances at the same time.
module TH.Derive

This module implements a system for registering and using typeclass derivers and instantiators. This allows you to derive instances for typeclasses beyond GHC's ability to generate instances in deriving clauses. For example, TH.Derive.Storable defines a Deriver for Storable. This allows us to use derive to generate an instance for Storable:
```
data X = X Int Float

$($(derive [d|
instance Deriving (Storable X)
|]))
```
In particular, note the use of double splicing, $($(derive [d| ... |])). The inner $(derive [d| ... |]) expression generates code which invokes the runDeriver method with appropriate arguments. The outer $( ... $) then runs that code in order to generate the resulting instances. This is how it does dispatch at compile time. There are a number of advantages of re-using instance syntax in this way:
- It allows the user to specify constraints. Similarly to GHC's need for standalone deriving, it is sometimes very difficult for TH to figure out appropriate superclass constraints.
- The instance gets thoroughly checked by GHC (syntax, kind, and type checking). This means that you get reasonably nice error messages when you misuse these.
- It allows the user to specify methods. With Instantiators, the user can provide values which can be used in the definition of the generated instance. This is a bit like having Instance Templates. We don't have pretty ways of writing these quite yet, but I have worked on something similar in the past.
- Using compile-time dispatch allows for concise specification of a multiple of instances you'd like derived.
- In the case of use of a Derivers, the user doesn't need to know about anything but derive and the name of the class they want. (and the Deriver instance must be in scope one way or another)
module Capability.Derive

No documentation available.
module Conjure.Conjurable.Derive

Allows automatic derivation of Conjurable typeclass instances.
Derive :: forall a . Columnable a => Text -> Expr a -> LazyOperation

dataframe DataFrame.Lazy

No documentation available.
module Test.Extrapolate.Generalizable.Derive

This module is part of Extrapolate, a library for generalization of counter-examples. This is a module for deriving Generalizable instances. Needs GHC and Template Haskell (tested on GHC 8.0). If Extrapolate does not compile under later GHCs, this module is the probable culprit.
module Test.FitSpec.Derive

Experimental module for deriving Mutable and ShowMutable instances Needs GHC and Template Haskell (tested on GHC 7.4, 7.6, 7.8, 7.10 and 8.0) Despite Mutable instances being actually very simple to write manually, this module can be used to derive those instances automatically. However, it will not work on all cases: when that happens, you should write your instances manually. If FitSpec does not compile under later GHCs, this module is probably the culprit.
module Grisette.Internal.TH.Derivation.Derive

No documentation available.
module Grisette.Internal.Utils.Derive

No documentation available.
module MCP.Server.Derive

No documentation available.

dataframe	DataFrame.Lazy

Page 2 of many | Previous | Next