Hoogle Search

Within LTS Haskell 24.52 (ghc-9.10.3)

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

  1. module Agda.TypeChecking.Pretty

    No documentation available.

  2. newtype PrettyContext

    Agda Agda.TypeChecking.Pretty

    No documentation available.

  3. PrettyContext :: Context -> PrettyContext

    Agda Agda.TypeChecking.Pretty

    No documentation available.

  4. class PrettyTCM a

    Agda Agda.TypeChecking.Pretty

    No documentation available.

  5. class PrettyTCMWithNode a

    Agda Agda.TypeChecking.Pretty

    Pretty-print something paired with a (printable) node. | This intermediate typeclass exists to avoid UndecidableInstances.

  6. module Agda.TypeChecking.Primitive

    Primitive functions, such as addition on builtin integers.

  7. type Pred a = a -> Bool

    Agda Agda.TypeChecking.Primitive

    No documentation available.

  8. class PrimType a => PrimTerm a

    Agda Agda.TypeChecking.Primitive

    No documentation available.

  9. class PrimType a

    Agda Agda.TypeChecking.Primitive

    No documentation available.

  10. module Agda.TypeChecking.ProjectionLike

    Dropping initial arguments (`parameters') from a function which can be easily reconstructed from its principal argument. A function which has such parameters is called ``projection-like''. The motivation for this optimization comes from the use of nested records. First, let us look why proper projections need not store the parameters: The type of a projection f is of the form f : Γ → R Γ → C where R is the record type and C is the type of the field f. Given a projection application p pars u we know that the type of the principal argument u is u : R pars thus, the parameters pars are redundant in the projection application if we can always infer the type of u. For projections, this is case, because the principal argument u must be neutral; otherwise, if it was a record value, we would have a redex, yet Agda maintains a β-normal form. The situation for projections can be generalized to ``projection-like'' functions f. Conditions:

    1. The type of f is of the form f : Γ → D Γ → ... for some type constructor D which can never reduce.
    2. For every reduced welltyped application f pars u ..., the type of u is inferable.
    This then allows pars to be dropped always. Condition 2 is approximated by a bunch of criteria, for details see function makeProjection. Typical projection-like functions are compositions of projections which arise from nested records. Notes:
    1. This analysis could be dualized to ``constructor-like'' functions whose parameters are reconstructable from the target type. But such functions would need to be fully applied.
    2. A more general analysis of which arguments are reconstructible can be found inJason C. Reed, Redundancy elimination for LF LFTMP 2004.

Page 1145 of many | Previous | Next