Hoogle Search

Within LTS Haskell 19.13 (ghc-9.0.2)

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

  1. derive :: ByteArrayAccess nonce => State -> nonce -> State

    cryptonite Crypto.Cipher.XSalsa

    Use an already initialized context and new nonce material to derive another XSalsa context. This allows a multi-level cascade where a first key k1 and nonce n1 is used to get HState(k1,n1), and this value is then used as key k2 to build XSalsa(k2,n2). Function initialize is to be called with the first 192 bits of n1|n2, and the call to derive should add the remaining 128 bits. The output context always uses the same number of rounds as the input context.

  2. derive :: DecsQ -> ExpQ

    th-utilities TH.Derive

    This is the primary function for users of TH.Derive. See the module documentation for usage info.

  3. module Test.LeanCheck.Derive

    This module is part of LeanCheck, a simple enumerative property-based testing library. Needs GHC and Template Haskell (tested on GHC 7.4, 7.6, 7.8, 7.10, 8.0, 8.2, 8.4, 8.6 and 8.8). If LeanCheck does not compile under later GHCs, this module is probably the culprit. If you rather do this through GHC Generics, please see: Test.LeanCheck.Generic (experimental).

  4. module Data.Express.Express.Derive

    Allows automatic derivation of Express typeclass instances.

  5. module Data.Express.Name.Derive

    Allows automatic derivation of Name typeclass instances.

  6. 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.

  7. module Data.Label.Derive

    Template Haskell functions for automatically generating labels for algebraic datatypes, newtypes and GADTs. There are two basic modes of label generation, the mkLabels family of functions create labels (and optionally type signatures) in scope as top level funtions, the getLabel family of funtions create labels as expressions that can be named and typed manually. In the case of multi-constructor datatypes some fields might not always be available and the derived labels will be partial. Partial labels are provided with an additional type context that forces them to be only usable in the Partial or Failing context.

  8. 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)

  9. module Capability.Derive

    No documentation available.

  10. module Conjure.Conjurable.Derive

    Allows automatic derivation of Conjurable typeclass instances.

Page 1 of many | Next