name: yoko
version: 0.3.1
synopsis: Generic Programming with Disbanded Data Types

description:
  Based off of the paper \"A Pattern for Almost Homomorphic Functions\" at <http://www.ittc.ku.edu/~nfrisby/papers/yoko.pdf>, submitted to ICFP 2012.
  .
  @yoko@ views a nominal datatype as a /band/ of constructors, each
  a nominal type in its own right. Such datatypes can be disbanded via the
  @disband@ function into an anonymous sum of nominal constructors, and vice
  versa via the @band@ function. This library uses extensive type-level
  programming to enrich its @instant-generics@ foundation with capabilities
  derived from the constructor-centric perspective.
  .
  For example, consider the following /nominal datatype/.
  .
  @
    data Beatles = John ... | Paul ... | George ... | Ringo ...
  @
  .
  This type can of course be understood as a sum of the individual
  /constructor types/.
  .
  @
    data John   = John   ...
    data Paul   = Paul   ...
    data George = George ...
    data Ringo  = Ringo  ...
  @
  .
  @yoko@'s conceptual foundations start there. In particular, this allows a
  constructor, say @John@, to be used independently of its original range type
  and sibling constructors.
  .
  As a generic programming library, @yoko@ extends @instant-generics@ with
  support for constructor-centric generic programming. The @Examples/LambdaLift/@
  file distributed with the @yoko@ source demonstrates defining a
  lambda-lifting conversion between the two types @ULC@, which has lambdas,
  and @Prog@, which has top-level function declarations instead.
  .
  @
    data ULC = Lam Type ULC | Var Int | Let [Decl] ULC | App ULC ULC
  .
    data Decl = Decl Type ULC
  .
  .
  .
    data Prog = Prog [FunDec] TLF
    type FunDec = ([Type], [Type], Type, TLF)
  .
    data TLF = Top Int [Occ] | Occ Occ | App TLF TLF
    data Occ = Par Int | Env Int
  @
  .
  These types are defined in separate modules, since they have constructors
  with the same name. Indeed, the fact that they having matching constructors
  named @App@ is crucial for @yoko@'s automatic conversion from @ULC@'s @App@
  to @TLF@'s @App@. As written, the generic lambda-lifter would continue to
  work for any new @ULC@ constructors (e.g. syntax for tuples or mutable
  references) as long as constructors with the same names and analogous fields
  were added to @TLF@ and the semantics of those constructors doesn't involve
  binding. This default behavior of the lambda-lifter is specified in about ten
  lines of user code.
  .
  Existing generic libraries don't use constructor names to the degree that
  @yoko@ does, and so cannot accomodate generic /conversions/ as well.

category: Generics, Reflection

license: BSD3
license-file: LICENSE
author: Nicolas Frisby <nicolas.frisby@gmail.com>
maintainer: Nicolas Frisby <nicolas.frisby@gmail.com>
stability: experimental

build-type: Simple
cabal-version: >= 1.6

extra-source-files: README, CHANGES, Examples/*.hs



library
  build-depends: base >= 4 && < 5,
                 template-haskell > 2.7 && < 2.8,
                 containers >= 0.4 && < 0.5,
                 mtl >= 2.0 && < 2.1
  build-depends: type-equality < 0.2

  build-depends:
    kinds >= 0.0.1.5 && < 0.1,
    type-functions >= 0.2.0.3 && < 0.3,
    records >= 0.1.1.6 && < 0.2

  build-depends:
    th-sccs < 0.1,
    type-booleans < 0.2,
    type-spine >= 0.1.1 && < 0.2,
    tagged-th < 0.2,
    type-digits < 0.2,
    type-cereal >= 0.1.1 && < 0.2,
    type-ord < 0.2,
    type-ord-spine-cereal < 0.2

  exposed-modules:
    Data.Yoko, Data.Yoko.HCompos, Data.Yoko.TH

    Data.Yoko.TypeBasics, Data.Yoko.Each

  other-modules:
    Data.Yoko.View,
    Data.Yoko.MaybeKind,
    Data.Yoko.Representation,
    Data.Yoko.TypeSums,
    Data.Yoko.TypeSumsAux,
    Data.Yoko.TH.Internal

    -- under development
--    Data.Yoko.Fold,
--    Data.Yoko.Map,
--    Data.Yoko.OnRs